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1 

BACKGROUND 


“The  essential  condition  for  an  army  to  be  able  to  withstand  the  strain  of 
the  battle  is  an  adequate  stock  of  weapons,  petrol,  and  ammunition.  In 
fact,  the  battle  is  fought  and  decided  by  the  quartermaster  before  the 
shooting  begins.  The  bravest  men  can  do  nothing  without  guns  nor  am¬ 
munition;  and  neither  guns  nor  ammunition  are  of  much  use  in  mobile 
warfare  unless  there  are  vehicles  with  sufficient  petrol  to  haul  them 
around.  Maintenance  must  also  approximate  in  quantity  to  that  available 
to  the  enemy.  ” 

Field  Marshal  Erwin  Rommel 


“...no  writer  has  ever  succeeded  in  glamorizing  it.  The  result  is  that  lo¬ 
gistics  are  usually  either  downplayed  or  ignored  altogether.  But  logistics 
were  the  lifeblood  of  the  Allied  armies  in  France.  Without  ports  and  fa¬ 
cilities  we  could  not  move,  shoot,  eat,  land  new  troops  or  evacuate  the 
wounded.  ” 

A  General’s  Life 
by  Omar  N.  Bradley 


1.1  THE  COLD  WAR  YEARS 


In  the  years  following  World  War  II,  the  United  States  entered  a  period  of  technological 
competition  with  the  then  Soviet  Union  called  the  Cold  War.  It  was  a  classic  quality  ver¬ 
sus  quantity  confrontation.  The  Soviets  designed  and  buUt  tough,  technically  simple,  it¬ 
erative  systems  that  could  be  produced  in  large  numbers.  The  United  States  usually  chose 
the  latest  technological  solution  and  relied  on  projected  higher  “kill  ratios”  to  prevail  in 
combat  even  if  the  confrontations  were  between  Soviet  and  U.S.  Third- World  clients. 

By  the  middle  of  the  1960s,  a  terrible  truth  was  obvious  about  the  U.S.  commitment  to 
high  technology.  Our  systems  were  fragile,  expensive  to  support,  and  short-lived  when 
employed.  The  F-1 1 1  aircraft  was  the  classic  example.  Brilliant  in  concept,  it  was  formi¬ 
dable  on  the  rare  occasion  when  everything  worked  and  lasted  for  the  duration  of  a  mis¬ 
sion.  The  amount  of  equipment  and  number  of  personnel  required  to  support  that  aircraft 
and  the  support  costs  involved  were  shocking.  A  new  philosophical  approach  was  defi¬ 
nitely  required. 
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The  philosophy  was  simple  to  state:  Influence  the  design  of  a  system  from  its  conception 
so  that  support  was  considered  and  life-cycle  costs  minimized.  The  implementation  was 
more  difficult.  The  iterative  nature  of  the  design  and  manufacturing  process  created  disci¬ 
plinary  “stovepipes”  that  resisted  the  intrusion  of  support  considerations  on  design,  and 
the  logisticians  lacked  an  effective  tool-set  to  credibly  present  their  arguments.  Intuition 
wasn’t  good  enough. 


Adapted  from  Romer,  Richard:  ‘The  Barbarians 
at  the  Gate,”  Logistics  Spectrum,  Fall  1994. 

1.2  THE  CHANGING  ACQUISITION  PROCESS 

Over  the  past  30  years,  acquisition  professionals  have  witnessed  numerous  changes  in  De¬ 
partment  of  Defense  policy  dealing  with  research  and  development  and  the  procurement  of 
systems  and  their  support.  Early  directives  emphasized  an  arms-length  relationship  with 
the  defense  industry,  compliance  with  detailed  regulations,  cumbersome  non-value  added 
processes,  and  costly  oversight/how-to-do-it  procedures  for  the  design  and  manufacture  of 
our  sophisticated  defense  systems.  Interim  policies  stressed  multi-layered  review  proc¬ 
esses  to  reduce  risk  and  cost  growth  while  somehow  meeting  fixed  program  schedules. 

This  same  period  also  witnessed  phenomenal  technological  advances  in  the  development 
of  software,  computer  hardware,  electronics,  aviation,  and  missile  systems. 

From  the  point  of  view  of  the  system  Program  Manager  (PM),  the  management  environment 
was  difficult  at  best  and  few  major  programs  enjoyed  the  reputation  of  meeting  initial  cost, 
schedule,  and  sometimes,  performance  objectives.  Life  was  not  easy  for  acquisition  logisticians 
either.  Although  “Concurrent  Engineering”  (which  has  some  aspects  of  today’s  Integrated 
Product  and  Process  Development)  was  established  in  the  late  1970’s,  program  office  func¬ 
tionals  operated  as  “stove  pipe”  activities  in  a  loose  alliance  trying  to  meet  common  objectives. 

1.3  A  NEW  WAY  OF  DOING  BUSINESS 


However,  1996  was  a  banner  year  for  acquisition  policy  changes.  Defense  policies  now 
included  acquisition  streamlining,  integrated  product  development,  performance  specifica¬ 
tions,  and  the  non-use  of  military  specifications  and  standards.  Many  PMs  dedicated  many 
labor  hours  to  implementing  these  new  policies.  The  15  March  1996  reissuance  of  DoDD 
5000.1  and  DoD  5000.2-R  (later  with  change  1  of  13  December  1996)  promulgated  these 
policy  changes  in  directive  format.  Just  another  change,  not  hardly! 

The  March  1996  polices  are  revolutionary.  This  is  Not  Business  as  Usual!  The  major 
thrusts  of  the  new  policies  are  teamwork  (integrated  product  teams),  teamwork  with 
industry,  tailoring,  empowerment,  only  performing  value-adding  tasks,  employing  Cost  As 
an  independent  Variable  (CAIV),  a  preference  for  commercial  items,  and  use  of  best  prac¬ 
tices.  This  guide  will  expand  on  these  themes. 
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1.4  NATIONAL  PERFORMANCE  REVIEW 


In  March  1993,  President  Clinton  announced  an  initiative  to  “reinvent  government”  called 
The  National  Performance  Review  (NPR).  In  Vice  President  Gore’s  Third  Report  of  the 
NPR  (1996),  the  following  statement  is  made  in  Chapter  1; 

“If  you’re  a  citizen,  you  ought  to  be  able  to  expect  good  services  from 
your  government.  If  you  run  a  business,  you  ought  to  be  able  to  expect 
reasonable  treatment  by  regulators  —  treatment  that  meets  legitimate 
pubhc  needs  without  crushing  yours.  And  as  a  taxpayer,  you  ought  to 
be  able  to  expect  that  the  government,  acting  as  your  trustee,  is  man¬ 
aging  your  tax  dollars  wisely.  And  the  federal  government  shouldn’t 
expect  applause  when  it  finally  straightens  things  out  to  give  the  Ameri¬ 
can  people  this  kind  of  treatment. 

“But  the  point  is,  this  has  never  happened  before.  Despite  1 1  major  ex¬ 
ercises  in  government  reform  this  century,  there’s  been  httle  lasting 
change.” 

The  1994  report  went  on  to  note  that  federal  spending  exceeds  23  percent  of  the  econ¬ 
omy,  and  that  the  Department  of  Health  and  Human  Services,  the  Department  of  Defense, 
and  the  Department  of  the  Treasury  each  spend  three  times  annually  what  America’s  larg¬ 
est  corporation.  General  Motors,'  takes  in  revenue. 

Chapter  4  of  the  1994  report  of  the  NPR  notes  that  because  the  1993  agreement  between 
the  Administration  and  Congress  will  keep  spending  tight  for  the  foreseeable  future,  the 
federal  government  must  find  ways  to  spend  the  money  it  has  more  effectively.  The  situa¬ 
tion  requires,  in  essence,  a  new  philosophy  of  governing  that  places  a  premium  on  cost- 
effectiveness.  In  a  section  on  red  ink,  the  report  states,  in  part: 

“What  the  government  needs,  then,  is  a  new,  more  efficient  way  to  dehver  basic 
services.  ...  A  key  element  in  the  revised  deficit  forecasts  are  [sic]  strict 
new  caps  on  annual  spending.”... 

This  Chapter  concludes: 

“Forced  to  do  better  —  to  provide  improved  customer  service  at  lower 
costs  —  agencies  and  employees  need  the  management  principles  and 
philosophies  embedded  in  From  Red  Tape  to  Results  and  this  year’s  an¬ 
niversary  update  (1993  and  1994  references  noted  above).  They  con¬ 
tain  the  key  to  effective  governing,  the  method  of  performing  within  the 
box  of  fiscal  constraint.” 


*  Budget  of  the  United  States  Government:  Fiscal  Year  1995,  p.l57 
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The  latest  NPR  reports  for  1996  are  benchmarking  studies,  which  include  industry 
participation  and  deal  with  resolving  customer  complaints. 

1.5  END  OF  THE  MONOLITHIC  SOVIET  CHALLENGE 


The  Cold  War  between  the  United  States  and  ultimately  its  Western  allies,  against  the  So¬ 
viet  Union  and  ultimately  the  Warsaw  Pact,  lasted  from  shortly  after  the  end  of  World  War 
II  (Berlin  Airlift,  1947)  until  1992. 

During  this  45-year  period,  the  United  States  and  its  allies  engaged  in  political  and  military 
combat,  both  directly  and  indirectly  (through  surrogates),  with  the  monolithic  threat  of  the 
Soviet  Union  for  control  over  the  Eurasian  land  mass.  The  winning  strategy  for  the 
United  States  came  first  from  forging  a  coalition  of  nations  in  the  late  1940s,  intervention 
in  the  Korean  War  and  the  building  of  NATO  in  the  1950s,  the  build-up  of  strategic  forces 
in  the  1960s,  establishing  relations  with  China  in  the  1970s,  and  the  United  States  arms 
build-up  of  the  1980s.  Errors  were  also  made  by  the  Soviets  along  the  way.  According  to 
Zbigniew  Brzezinski,  President  Carter’s  national  security  adviser,  American  policy  (for¬ 
eign  and  military)  may  not  have  been  brilliant  and,  at  times,  it  was  overly  defensive,  but  it 
was  steady.^ 

The  breakup  of  the  Soviet  Union  has  not  ended  aU  threats  to  U.S.  national  security.  Ac¬ 
cordingly,  ‘The  primary  task  of  the  Armed  Forces  of  the  United  States  will  remain  to  de¬ 
ter  conflict  —  but,  should  deterrence  fail,  to  fight  and  win  our  nation’s  wars.  In  addition, 
we  should  expect  to  participate  in  a  broad  range  of  deterrent,  conflict  prevention,  and 
peacetime  activities.”^ 

1.6  PUBLIC  DEMAND  FOR  DOWNSIZING  GOVERNMENT 
1.6.1  The  Current  Threat 

The  prior  two  sections  provide  some  of  the  logic  driving  Congress  to  downsize  govern¬ 
ment  by  taking  aim  at  a  reduced  annual  federal  budget  deficit.  This  action  began  in  the 
early  nineties  and  continues  today.  As  the  Department  of  Defense  downsizes  its  very  large 
proportion  of  the  federal  government  in  terms  of  people  and  appropriated  funds,  consider¬ 
ation  must  continue  to  be  given  to  threats  to  the  security  of  the  United  States  and  DoD’s 
role  in  implementing  the  President’s  foreign  policy.  Previously  existing  threats  to  the 
United  States  have  shifted  and  diminished,  while  new  threats  have  evolved.  Currently 
(1997),  the  principal  threats  to  U.  S.  interests  are  North  Korea,  political/military  develop¬ 
ments  in  Russia,  continuing  Middle  East  instability,  and  the  proliferation  of  technology 
associated  with  weapons  of  mass  destruction  in  the  hands  of  various  rogue  nations.  Add 
to  this  transnational  and  subnational  conflicts,  some  of  which  may  impact  U.S.  interest. 
Thus,  with  the  world’s  major  militaries  now  in  a  decade  of  transition  (the  end  points  of 
which  are  not  entirely  clear)  we  face  a  high  degree  of  uncertainty  regarding  the  nature  of 

■  Brzezinski,  Zbigniew  ‘The  Cold  War  And  Its  Aftermath,”  Foreign  Affairs,  p.  31,  Fall  1992. 

^  Joint  Vision  2010,  Chairman  Joint  Chiefs  of  Staff,  John  M.  Shalikashvili,  General,  USA. 
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the  threats  that  will  eonfront  U.S.  interests  in  the  early  21st  century.  In  addition,  the  end 
of  the  Cold  War  is  still  playing  itself  out,  and  as  a  result  of  decreasing  threat  perceptions 
and  generally  declining  defense  budgets  (China  being  a  notable  exception),  mihtaries  are 
not  enjoying  the  resource  prominence  they  once  did.  In  summary,  direct  threats  to  the 
security  interest  and  territorial  integrity  of  the  United  States  have  declined  over  the  last 
several  years,  but  mid-range  dangers  and  long-range  uncertainties  continue  to  be  at  the 
forefront  of  U.S.  national  security  policy.'^ 

The  national  security  of  the  U.S.  is  made  up  of  a  strategy  that  has  three  components:  pre¬ 
vent  and  reduce  the  threat,  deter  the  threat,  and  defend  against  the  threat.  The  first  com¬ 
ponent,  prevention,  consists  primarily  of  treaties  with  other  nations  together  with  diplo¬ 
matic  and  other  cooperative  activities.  The  second,  deter,  involves  the  strategic  nuclear 
forces  that  have  been  the  bulwark  of  that  deterrence  for  nearly  half  a  century.  To  the  ex¬ 
tent  these  first  two  components  are  not  fully  successful,  we  have  to  be  prepared  to  defend 
directly  against  a  threat.  Thus,  defenses,  in  varying  degrees  and  with  various  levels  of  ur¬ 
gency,  are  linked  to  the  threat  from  a  range  of  weapons  and  several  groups  of  nations. 

The  weapons  stiU  include  strategic  ballistic  missiles  plus  developing  medium,  and  short- 
range  ballistic  missiles  and  land-attack  cruise  missiles.  Any  of  these  weapons  can  be 
armed  with  nuclear,  biological,  or  chemical  warheads.  The  threat  from  some  nations  with 
large  inventories  of  these  weapons  is  currently  quite  low,  while  the  threat  from  other  na¬ 
tions  who  want  to  own  these  weapons  may  be  relatively  high.  The  nations  with  large  in¬ 
ventories  include  Russia  and  mainland  China.  Other  nations  getting  special  attention 
include  North  Korea  and  a  group  of  rogue  nations  such  as  Iraq.^ 

1.6.2  Downsizing 

The  end  of  the  Cold  War  has  resulted  in  a  deliberate  major  reduction  in  all  aspects  of  the 
armed  forces  of  the  United  States.  The  execution  of  this  reduction  has  been  referred  to  as 
downsizing.  It  has  also  caused  a  major  reduction  to  take  place  in  the  capacity  of  the  de¬ 
fense  industry.  Downsizing  has  resulted  in  a  restructuring  of  our  defense  acquisition  proc¬ 
ess  based  on  modern  management  techniques  and  the  adoption  of  best  practices,  as  appro¬ 
priate,  from  the  private  sector  and  from  within  DoD. 

1 .6.2. 1  Downsizing  To  Date.  A  summary  of  downsizing  until  the  present  was  provided 
by  the  Secretary  of  Defense  when  he  said,  ‘The  forces  which  we  use  today  to  carry  out 
our  deter  or  defeat  strategy  are  dramatically  changed  from  the  Cold  War  days.  Since  the 
mid-1980s,  we  have  cut  our  defense  budget  by  40  percent,  cut  our  forces  by  30  percent — to 
include  withdrawing  two-thirds  of  the  ground  forces  and  three-quarters  of  our  air  forces 
from  Europe,  and  cut  our  weapon  acquisition  by  70  percent.  At  the  same  time,  we 


This  paragraph  adapted  from  Defense  Issues,  Vol.  10,  Nr.  5,  “The  Worldwide  Threat  to  U.S.  Interest,”  a 
prepared  statement  of  Lt.  Gen.  James  R.  Clapper,  Jr.,  USAF,  Director,  Defense  Intellegence  Agency,  to 
the  Senate  Armed  Services  Committee,  Jan.  17,  1995. 

^  Adapted  from  Defense  Issues,  Vol.  11,  Nr.  92,  “Dark  Clouds  of  Nuclear  War  Threat  Fading,  But  Not 
Gone,”  prepared  remarks  by  Paul  G.  Kaminsky,  USD(A&T),  to  the  Military  Research  and  Development 
and  Procurement  subcommittees.  House  National  Security  Committee,  Sept.  27,  1996. 
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discarded  our  strategies  designed  to  fight  a  major  war  in  Europe  and  developed  new 
strategies  and  tactics  for  deterring  and  fighting  regional  conflicts.  We  reoriented  our 
training  centers  to  focus  on  this  kind  of  conflict  as  well  as  other  potential  threats.  For  ex¬ 
ample,  in  order  to  get  ready  for  Bosnia,  we  turned  one  of  our  training  centers  in  Germany 
into  a  mini-Bosnia,  complete  with  burned-out  villages,  refugees  and  paramilitary  forces. 
And  finally,  we  focused  on  quality  —  quality  weapons  systems,  quality  people  and  quality 
living  conditions  for  our  troops  and  their  families.”® 

Contributing  to  downsizing  are  several  DoD  initiatives  and  administration  policies. 

1. 6.2.2  Modernization.  Modernization  does  not  only  mean  new  systems  or  upgrades  to 
existing  systems.  It  also  means  joint  planning  and  joint  training.  It  means  small  procure¬ 
ments  of  essentials  such  as  tactical  communications,  trucks,  ammunition,  armored  person¬ 
nel  carriers,  etc.  When  applied  to  a  major  program  such  as  shipbuilding,  modernization 
means  a  submarine  or  surface  combatant  being  fuUy  capable  of  participating  in  joint  op¬ 
erations.  Thus,  the  jointness  aspect  of  modernization  takes  a  lot  of  training,  cooperation, 
and  trust  among  the  Services.  It  is  not  easy,  but  it  is  critically  important.  Modernization 
when  combined  with  readiness  in  the  context  of  a  smaller  force  structure,  in  the  words  of 
former  Secretary  of  Defense  Perry,  gives  us  more  than  mere  technological  superiority;  it 
gives  us  a  force  that  is  capable  of  dominating  any  potential  foe  across  the  full  spectrum  of 
military  operations.  In  this  regard,  the  Deputy  Undersecretary  of  Defense  for  Acquisition 
Reform  noted  early  in  1995  that  in  what  was  then  the  10th  year  of  declining  defense  budg¬ 
ets,  it  was  time  to  start  investing  in  modernization  again  in  view  of  the  fact  that  the  cas¬ 
cading  effect  of  modem  equipment  going  to  a  smaller  number  of  troops  had  run  its  course. 

The  base  realignment  and  closure  process  is  also  linked  to  modernization  and  long-term 
readiness.  Former  Secretary  of  Defense  Perry  stated  that  as  we  downsize  the  military 
force,  we  must  also  reduce  our  Cold  War  infrastructure.  Future  efforts  will  be  aimed  at 
correcting  the  imbalances  between  force  structure  and  infrastructure  that  remain. 

1.6.2. 3  Science  and  Technology  (S&Tl.  The  emphasis  placed  on  this  area  was  best  ex¬ 
plained  by  Secretary  of  Defense  Perry  in  May  1996  when  he  noted,  ‘The  challenge  for  the 
Department’s  science  and  technology  program  is  to  put  the  best  available  technology  into 
the  hands  of  the  customer  —  the  warfighter  —  in  a  way  that  is  timely  and  cost  effective 
both  tomorrow  and  far  into  the  future.  Doing  this  requires  close,  continuous  and  effective 
interaction  between  our  warfighters  and  our  technology  managers.  It  also  requires  main¬ 
taining  a  world-class  base  of  people  and  facilities.  We  have  such  a  base  today.  I  am 
committed  to  maintaining  it  into  the  future.  Our  Science  and  Technology  program  will 
keep  our  warfighters  at  the  cutting  edge  of  new  technology  and  ensure  our  dominance  on 
future  battlefields.” 


*  Defense  Issues,  Vol.  11,  Nr.  97,  “A  pragmatic  U.S. -Russian  Partnership,”  prepared  remarks  by  SecDef 
William  J.  Perry  to  the  Military  Academy  of  the  Russian  General  Staff,  Moscow,  Oct.  17,  1996. 
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1.6.3  Paucity  of  New  Program  Starts 

Clearly  the  Department  of  Defense  is  pursuing  fewer  major  system  development  programs 
and  has  been  provided  with  significantly  reduced  R&D  and  procurement  fimds  as  com¬ 
pared  with  the  recent  past.  In  fact,  the  real  value  of  defense  spending  has  declined  in  each 
of  the  last  1 1  years  since  1986  —  through  the  last  three  years  of  the  Reagan  administra¬ 
tion,  through  Desert  Storm  and  the  Bush  administration,  and  now  through  the  Clinton 
administration.  This  trend  began  before  the  fall  of  the  Berlin  Wall  and  has  spanned  two 
Republican  and  one  Democrat  administration.’  Continuing  pressure  will  be  exerted  to 
further  reduce  the  defense  budget  in  the  years  to  come.  This,  combined  with  the  change  in 
threat  noted  above,  results  in  the  paucity  of  new  program  starts  (in  1997).  Thus,  the  issue 
may  be,  how  to  make  the  best  of  this? 

The  former  Under  Secretary  of  Defense  (Acquisition  &  Technology)  Paul  Kaminski  was 
promoting  three  points  in  this  regard:  the  continuation  of  a  movement  from  separate  de¬ 
fense  and  commercial  industrial  sectors  to  one  integrated  industrial  base,  furthering  de¬ 
fense  industry  restructuring  and  consolidation,  and  expanding  the  opportunities  for  arma¬ 
ments  cooperation  and  using  that  cooperation  to  better  integrate  and  rationalize  our  in¬ 
dustries.  He  also  gave  emphasis  to  increasing  DoD  reliance  on  dual-use  technologies, 
products,  and  processes. 

Today's  global  economy  allows  everyone,  including  potential  adversaries,  to  gain 
increasing  access  to  the  same  commercial  technology  base.  This  increased  access  is  fur¬ 
ther  justification  for  DoD  to  pursue  a  dual-use  strategy  in  order  to  break  down  the  barriers 
between  commercial  and  defense  industries,  to  realize  the  benefits  of  commercial-military 
integration  in  both  research  and  development  and  in  manufacturing,  to  increase  the  pace  of 
innovation  in  defense  systems,  and  to  reduce  the  cost  of  such  systems.  The  bottom  line  is 
that  we  have  no  choice  but  to  move  fi’om  separate  industrial  sectors  and  marry  the  mo¬ 
mentum  of  a  vigorous,  productive,  and  competitive  commercial  industrial  infrastructure 
with  the  unique  technologies  and  systems  integration  capabilities  provided  by  our  defense 
contractors. 

The  world-wide  defense  industry  is  dealing  with  excess  capacity.  Mergers  and  combina¬ 
tions  of  companies  are  taking  place  in  the  United  States.  For  many  countries  in  Europe, 
aerospace  firms  with  long  and  distinguished  histories  have  been  privatized,  merged,  or 
even  closed.  Industrial  base  considerations  are  becoming  more  important  to  our  national 
and  international  security  postures.  In  the  interest  of  caution,  DoD  has  conducted  assess¬ 
ments  of  some  sectors  of  the  U.S.  defense  industry  to  determine  what  capabilities  are  es¬ 
sential  to  support  our  defense  needs;  whether  or  not  those  capabilities  are  truly  unique; 
and  whether  or  not  those  capabilities  are  “endangered.”  In  1996,  the  department  com¬ 
pleted  studies  of  the  industry  supporting  conventional  ammunition  and  tracked  combat 


’  Defense  Issues,  Vol.  1 1,  Nr.  85,  “Defense  Industry  Challenges  and  Opportunities,”  prepared  remarks  by 
USD(A&T)  Paul  G.  Kaminski  to  the  Silicon  Valley/Space  Consortium  2nd  Annual  Silicon  Valley  Defense 
Acquisition  Conference,  Santa  Clara,  Calif.,  July  11,  1996. 
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vehicles,  bombers,  helicopters,  destroyers,  nuclear  power  plants  for  submarines,  expend¬ 
able  space  launch  vehicles,  the  D-5  missile,  and  torpedoes.  These  studies  indicate  that  al¬ 
though  DoD  programs  will  not  sufficiently  sustain  aU  of  the  companies  currently  engaged 
in  defense-related  businesses,  the  scale  and  mix  of  the  DoD  programs  will  adequately  sus¬ 
tain  nearly  every  required  industrial  capability.  The  two  conclusions  are  that  there  are  vir¬ 
tually  no  sectors  where  the  capability  is  endangered;  and  DoD  should  not  take  direct  ac¬ 
tion  to  preserve  those  capabilities.^ 

As  previously  noted,  on  both  sides  of  the  Atlantic  defense  industrial  sectors  are  down¬ 
sizing.  The  United  States  stiU  has  perhaps  another  10  -percent  reduction  ahead,  and  DoD 
will  continue  to  face  pressures  to  reduce  its  budget.  DoD  is  dealing  with  this  environment 
of  fewer  new  program  starts  and  all  of  the  implications  of  this  reduction,  including  the  im¬ 
plementation  of  a  dual-use  strategy  and  a  broad  program  of  acquisition  reform  to  better 
integrate  the  defense  and  commercial  industrial  base.^ 

1.7  WHY  ACQUISITION  REFORM  NOW 


In  a  15  March  1994  memo,  former  Secretary  of  Defense  William  J.  Perry  promulgated  his 
9  February  1994  paper.  Acquisition  Reform  — A  Mandate  For  Change,  to  the  senior 
leadership  within  the  Department  of  Defense.  In  stating  the  problem  and  why  change  was 
necessary.  Secretary  Perry  noted  in  his  paper  that,  ‘The  Post-Cold  War  era  poses  a  new 
set  of  political,  economic,  and  military  security  challenges  for  the  United  States:  regional 
or  limited  conflicts;  proliferation  of  weapons  of  mass  destruction,  both  nuclear  and  non¬ 
nuclear;  risks  to  its  economic  well-being;  and  the  possible  failure  of  democratic  reform  in 
the  former  Soviet  Bloc  and  elsewhere.  The  President  and  Secretary  of  Defense  are  com¬ 
mitted  to  maintaining  the  U.S.  military’s  edge  over  opponents.  That  means  maintaining 
superior  people,  training,  logistics,  and  weapons  system  technology — the  advantage  the  U.S. 
now  has  that  allows  us  to  deter  aggression,  and  to  prevail  quickly  with  minimum  casualties 
when  required  to  employ  force.  The  President  and  Secretary  of  Defense  are  committed  to 
maintaining  a  lean,  high-tech,  agile,  ready-to-fight  military  force  during  a  time  in  which: 
the  threats  are  changing  and  unpredictable;  by  Fiscal  Year  1997  defense  spending  will 
have  declined  in  real  terms  by  over  40%  from  FY85;  and  advanced  technology  is  increas¬ 
ingly  available  to  the  world.” 

Examples  given  in  the  acquisition  reform  paper  of  situations  or  processes  that  justified 
“Acquisition  Reform”  in  1994,  some  of  which  still  require  work  in  1997,  and  beyond,  include: 

•  The  foundation  upon  which  our  national  security  strategy  has  been  buUt  was  un¬ 
dergoing  significant  change. 

•  The  DoD  procurement  rules  that  had  prevented  DoD  from  acquiring  state-of- 
the-art  commercial  technology  and  prevented  full  use  best  commercial  practices. 


*  Defense  Issues,  Vol  1 1,  Nr  84,  Paul  Kaminski,  USD(A&T),  Warsaw,  Poland,  June  21,  1996 
®  Ibid. 
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•  The  DoD  policies  that  had  prevented  the  Department  from  buying  from  certain 
companies  even  when  the  price  was  cheaper. 

•  The  years  of  contractor  and  DoD  staff  work  that  had  been  needed  to  obtain 
policy  waivers  to  allow  DoD  to  save  procurement  dollars. 

•  The  unwillingness  of  contractors  to  incur  the  costs  of  conplying  with  govern¬ 
ment  unique  and  costly  contract  terms  in  order  to  sell  to  DoD. 

•  The  DoD’s  excessively  high  cost  of  doing  business,  a  portion  of  which  is  due  to 
telling  contractors  how  to  do  the  job  as  opposed  to  providing  performance 
specifications. 

•  The  practices  within  DoD  that  prevented  the  rapid  acquisition  of  commercial 
technology. 

•  The  failure  of  DoD  to  consider  life-cycle  costs  at  all  times. 

•  The  need  to  free  up  resources  for  modernization  while  maintaining  the  DoD 
force  structure  and  readiness  levels. 

Former  Secretary  Perry  indicated  initiatives  relative  to  these  problems  and  many  more  had 
been  addressed  in  recent  years.  He  noted  that  Cost  As  an  Independent  Variable  (CAIV)  is 
essential  to  DoD  surviving  ever-decreasing  budgets.  He  further  stated  that  much  remains 
to  be  done  in  terms  of  acquisition  reform,  particularly  adjustments  to  restrictive  laws  rela¬ 
tive  to  outsourcing.  Therefore,  re-engineering  the  acquisition  process  has  been  and  will 
continue  to  be  a  high  DoD  priority.  Acquisition  processes  must  be  able  to  respond  to  ex¬ 
ternal  changes.  DoD  faces  new  national  security  challenges,  a  drastically  reduced  budget, 
reduced  influence  in  the  marketplace,  and  technology  that  is  changing  faster  than  the  sys¬ 
tem  can  respond;  and  that  technology  is  available  to  the  entire  world.  The  point  was  made 
that  we  must  design  an  acquisition  system  that  can  get  out  in  front  of  these  changes  in¬ 
stead  of  reacting  to  them. 

1.8  TECHNOLOGY  EXPLOSION 


“Our  forces  are  being  designed  to  achieve  dominant  battlefield  aware¬ 
ness  and  combat  superiority  through  the  deployment  of  fully  integrated 
intelhgence  systems  and  technologically  superior  weapons  systems. 
‘Dominant  battlefield  awareness’  means  knowing  everything  going  on 
in  a  battlefield  —  everything  within  an  area  that  can  measure  up  to  200 
kilometers  by  200  kilometers.  The  primary  objective  is  to  know  where 
aU  the  enemy  forces  are.  It  also  means  knowing  similar  information  re¬ 
garding  aU  friendly  forces  as  well.  However,  dominant  battlefield 
awareness  is  much  more  than  knowing  the  static  location  of  forces. 
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“Commanders  will  need  to  know  the  combat  readiness  status  of  ‘state 
vector’  for  each  force  element.  This  includes  knowing  the  logistics 
posture  of  friendly  and  enemy  forces  as  well  as  having  a  prediction  of 
the  resupply  needs  of  each  force  element.  There  is  a  strong  linkage 
between  dominant  battlefield  awareness  and  total  asset  visibility  —  without 
the  latter,  the  former  is  seriously  degraded.  To  complete  the  logistics 
picture,  available  support  and  the  need  for  future  support  must  be 
propagated  from  each  force  element  in  the  field  throughout  the  whole 
support  system.  It  will  require  a  seamless  logistics  system,  one  with 
modernized  information  systems  and  improved,  assured  communica¬ 
tions." 


— Paul  G.  Kaminsky,  USD(A&T),  1996,  Foreword  to  DoD 
Logistics  Strategic  Plan. 


1.8.1  Telecommunications 

Rapid  gains  in  telecommunications  permit  the  transfer  of  information  at  speeds  and  in 
quantities  only  dreamed  of  in  years  past.  For  the  first  time,  the  battlefield  commander 
has  the  opportunity  to  receive  comprehensive  real-time  information  relative  to  the  en¬ 
tire  battlefield;  subject  to  the  appropriate  deployment  of  data-gathering  sensors  such 
as  satellites,  ground  and  airborne  radars,  infrared  sensors,  etc.;  and  open  (unjammed) 
communication  links.  The  Joint  Surveillance  and  Targeting  Attack  Radar  System 
(JSTARS)  is  under  development  to  provide  a  meaningful  portion  of  the  sensor  suite 
and  telecommunications  network.  During  the  early  stages  of  Operation  Joint  En¬ 
deavor,  JSTARS  was  given  its  operational  christening  as  an  Advanced  Concept  Tech¬ 
nology  Demonstrator  in  Bosnia.  To  support  Implementation  Forces  (IFORs)  in  Bos¬ 
nia,  DoD  is  improving  force  communications  capabilities  in  two  ways.  First,  in  order 
to  provide  direct  broadcast  communications  capability,  commercial  television  satellite 
technology  is  being  used.  Second,  DoD  is  fielding  a  wide  bandwidth,  secure  tactical 
Internet  connection  through  fiber  and  commercial  satellite  transponders.  These  com¬ 
munications  allow  war  planners  and  logisticians,  on  the  ground  in  Bosnia,  in  the 
European  Command  headquarters  in  Germany,  and  in  the  Pentagon,  to  have  access  to 
the  same  data  at  the  same  time.  This  access  is  available  to  virtually  anyone  with  a  20- 
inch  receiver  antenna,  cryptologic  equipment,  and  authentication  codes.  Local  com¬ 
manders  have  a  5,000-mile  remote  control  to  select  the  programming  that  they  receive 
over  their  24  megabits-per-second  downlinks  from  direct  broadcast  satellites.  That 
power  in  telecommunications  holds  great  potential  for  modernizing  the  DoD  logistics 
support  system.  The  attainment  of  full,  real-time,  worldwide  asset  visibility  is  a  high 
DoD  priority. 

1.8.2  Computers 

The  explosive  growth  rate  in  computer  capability  and  the  steep  decline  in  the  cost  of  com¬ 
puters  are  common  knowledge.  Numerous  DoD  development  efforts  are  underway  to 
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apply  current  computational  powers  to  operational  and  logistics  uses.  Computer  technol¬ 
ogy,  spawned  by  the  military  but  now  fully  exploited  by  capable  commercial  entities,  has 
been  combined  with  telecommunications  technology  in  an  effort  to  attain  real-time  world¬ 
wide  logistics  asset  visibility. 

1.8.3  Increased  Potential  for  Flexible  Logistics 

During  the  1980s,  the  military  posture  of  the  United  States  focused  on  the  major 
threat  posed  by  the  Soviet  Union.  Following  the  collapse  of  the  Soviet  Union  in 
1989,  a  number  of  regional  conflicts  flared  up.  In  several  cases,  the  United  States 
played  a  role  with  its  military  forces,  either  for  humanitarian  purposes  or  to  further 
our  national  interests.  Current  DoD  plans  foresee  a  near-term  future  in  which  re¬ 
gional  conflicts  persist  but  which  is  devoid  of  a  major  military  threat  as  characterized 
by  the  45-year  Cold  War.  The  logistics  implications  associated  with  this  scenario 
once  again  dictate  the  attainment  of  fuU,  real-time  worldwide  asset  visibiUty,  rapid  de¬ 
ployment  of  forces  and  support  assets,  and  a  need  for  rapid  manufacturing  and  posi¬ 
tioning  of  logistics  elements. 

1.8.4  Multinational  Corporations  for  Worldwide  Support 

With  defense  posture  focused  on  regional  conflicts,  efforts  are  underway  to  develop  a 
network  of  multinational  corporations  with  overseas  supphers  to  provide  a  significant 
portion  of  logistics  support  at  points  closer  to  potential  future  conflicts.  The  Gulf 
War  demonstrated  the  enormity  of  the  task  of  positioning  a  major  force,  together  with 
its  logistics  tail,  adjacent  to  a  potential  or  actual  conflict  that  is  thousands  of  miles 
from  the  continental  United  States.  As  the  Services  shift  toward  a  leaner,  faster,  bet¬ 
ter  logistics  system,  the  availability  of  supply  sources  in  Europe  and  in  the  Far  East 
should  significantly  lessen  the  burden  on  the  transportation  system  and  reduce  supply 
response  times. 

1.9  LOGISTICS  STRATEGIC  PLAN 


The  previously  noted  Logistics  Strategic  Plan  (1996/1997  edition)  was  prepared  by 
the  Deputy  Under  Secretary  of  Defense  (Logistics)  and  promulgated  22  June  1996  by 
Under  Secretary  of  Defense  (Acquisition  and  Technology).  The  plan  states: 

“The  changing  threat  requires  that  logistics  be  flexible,  mobile,  inte¬ 
grated,  compatible,  and  precise  in  targeting  support  to  the  point  of 
need.  These  quahties  depend  on  highly  reliable,  near  real-time  infor¬ 
mation,  which  will  become  one  of  the  logisticians'  foremost  allies  in  the 
future.  At  the  same  time,  investments  are  needed  to  “engineer”  costs 
out  of  the  logistics  tail.  Some  of  these  investments  are  in  the  logistics 
system  itself,  while  others  will  be  needed  to  reduce  the  cost  of  main¬ 
taining  complex  system  components.  Achieving  world-class  capabili¬ 
ties,  while  reducing  the  cost  of  DoD's  logistics  system,  is  the  principal 
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challenge  of  this  Plan.  The  logistics  system  of  the  Department  is  part  of 
the  Nation's  industrial  and  logistics  capabihty;  and  a  rebalancing  of 
public  and  private  sector  logistics  delivery  methods  is  essential  to  en¬ 
sure  both  best  value  and  best  results.” 

In  urging  all  DoD  Components  to  incorporate  the  Plan  into  their  management  program¬ 
ming  and  budgeting  priorities,  the  following  is  offered  by  the  plan: 

Logistics  System  Mission  Statement 

“To  provide  responsive  support  to  ensure  readiness  and  sustainability 
for  the  Total  Force  in  both  peace  and  war.  ” 

Vision 

“The  DoD  Logistics  System  will: 

“Provide  rehable,  flexible,  cost-effective  and  prompt  logistics  support, 
information,  and  services  to  the  warfighters; 

“Achieve  a  lean  infrastructure; 

“The  DoD  Logistics  System  will  meet  this  vision  proactively  by  making 
selective  investments  in  technology;  training;  process  reengineering; 
and  employing  the  most  successful  commercial  and  government  sources 
and  practices.” 

1.10  FOCUS  ON  LIFE-CYCLE  COSTS  EFFICIENCY  AND  USE  OF 
COMMERCIAL  BEST  PRACTICES 

1.10.1  Outsourcing  and  Privatization*® 

1.10.1.1  Definitions,  (quoting  from  the  referenced  Defense  Science  Board  Report) 

•  “Outsourcing 

—  “Transfer  of  a  support  function  previously  performed  in- 
house  to  an  outside  service  provider. 

—  “Service  provider  usually  given  extensive  flexibility  regard¬ 
ing  how  it  performs  the  outsourced  function. 


Adapted  from  Report  of  the  Defense  Science  Board  Task  Force  on  Outsourcing  and  Privitization, 
OUSD(A&T),  August  1966. 
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•  “Privatization 

—  “A  type  of  outsourcing  involving  the  transfer  of  government 
assets  (depots,  data  centers,  etc.)  to  the  private  sector. 

—  “Government  sheds  capability  to  perform  the  outsourced 
task. 

—  “Most  DoD  outsourcing  initiatives  do  not  involve  privatiza¬ 
tion.” 

1.10.2  Background 

Outsourcing  and  privatization  will  become  increasingly  important  in  the  next  few  years. 
Full  implementation  is  critical  to  freeing  up  the  funds  essential  to  force  modernization.  In 
the  words  of  the  former  Under  Secretary  of  Defense  (Acquisition  and  Technology),  Paul 
G.  Kaminski: 

“DoD  must  continue  to  reduce  its  infrastructure  and  support  costs  to  in¬ 
crease  funding  for  modernization  in  the  coming  years.  Introducing  the 
competitive  forces  of  the  private  sector  into  DoD  support  activities  will  re¬ 
duce  costs  and  improve  performance.  Outsourcing  is  not  a  theory  based  on 
uncertain  assumptions.  Experience  in  DoD  and  the  private  sector  consis¬ 
tently  and  unambiguously  demonstrates  how  the  competitive  forces  of 
outsourcing  can  generate  cost  savings  and  improve  performance.  One 
need  only  glimpse  at  the  operation  of  our  nation’s  most  successful  compa¬ 
nies  to  see  the  dramatic  benefits  that  they  realize  through  outsourcing  and 
competition.” 

Similarly,  a  Defense  Science  Board  (DSB)  task  force  that  studied  outsourcing  and  privati¬ 
zation  stated  that  outsourcing  and  privatization  should  not  be  viewed  as  an  end  to  itself, 
but  as  the  only  practical  approach  to  free-up  the  resources  needed  to  ensure  the  continuing 
military  superiority  and  technological  leadership  of  the  U.S.  Armed  Forces. 

The  DoD  is  unlikely  to  obtain  significant  additional  resources  for  modernization  from  fur¬ 
ther  infrastructure  consolidation,  at  least  in  the  midterm.  The  Base  Realignment  and  Clo¬ 
sure  (BRAC)  Commission  completed  its  most  recent  round  of  base  closure  action  in  1995. 
While  the  BRAC  process  is  for  the  first  time  generating  net  savings  in  1996  (Transition 
costs  of  base  closure  actions  are  often  high.),  these  savings  have  already  been  incorporated 
into  the  current  Future  Year  Defense  Program.  Moreover,  congressional  interest  in 
authorizing  another  BRAC  round  any  time  soon  is  open  to  question. 

1.10.3  The  Support  Structure 

FuU-time  equivalents  (FTEs)  are  defined  as  the  man-years  of  work  elements  performed  by 
military  or  DoD  civilian  individuals  that  could  be  performed  by  non-DoD  commercial  ac¬ 
tivities.  In  FY94,  the  number  of  FTEs  was  640,000  (that  number  has  since  diminished  to 
an  estimated  figure  of  500,000).  Of  the  640,000  FTEs,  over  one-third  performed  depot- 
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level  or  intermediate  maintenanee.  Base  services  and  health  services  together  were  the 
other  major  sources  of  commercial  activity  FTEs.  These  categories  account  for  almost 
three-quarters  of  aU  commercial  FTEs  reported  in  FY94. 

1.10.4  Private  Sector  Experience 

U.S.  firms  increasingly  outsource  a  wide  range  of  support  functions  to  outside  vendors. 
Information  technology  (IT)  was  the  first  major  function  outsourced  beginning  in  the  mid- 
1980s.  In  1996,  IT  outsourcing  still  represents  a  major  share  of  aU  outsourcing  activity. 
Business  logistics,  manufacturing,  and  finance  and  administration  are  other  support  func¬ 
tions  with  strong  outsourcing  trends. 

1.10.5  Public  Sector  Experience 

In  summary,  the  public  sector  already  has  extensive,  highly  successful  experience  with 
outsourcing.  Despite  its  flawed  approach  to  outsourcing,  DoD  has  obtained  significant 
cost  savings  and  other  benefits  from  its  somewhat  limited  efforts  to  transfer  support  func¬ 
tions  to  the  private  sector.  However,  the  Department  has  outsourced  only  a  smaU  portion 
of  IT  commercial  activity  workload  (25  percent  of  850,000  positions  that  were  involved  in 
commercial- type  activities). 

DoD  success  stories  include; 

•  Air  Force  base  support:  outsourcing  aU  functions. 

—  Selected  CONUS  bases  (e.g.,  Vance). 

—  Overseas  bases  (e.g.,  Incirlik). 

•  Other  functions  have  had  strong  outsourcing  successes: 

—  DLA  materiel  management. 

—  Individual  skill  training. 

—  Depot-level  maintenance/overhaul. 

•  In- theater  outsoureing  results:  responsive,  reliable  support 
—  Telecommunication  in  Vietnam  War. 

—  Range  of  key  support  functions  in  Desert  Shield/Desert  Storm, 

—  Haiti,  and  Bosnia. 

•  Direct  vendor  delivery  (DVD): 

—  Vendor  delivers  against  DLA  contract  directly  to  customer. 

—  Improves  response,  reduces  inventory  and  infrastructure. 

—  DVD  is  $1.4B  or  32  percent  of  FY95  sales;  FY97  goal  is  50  percent 

•  Prime  vendor  contracts: 

—  Customers  deal  directly  with  vendor. 
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—  Medical  is  key  example: 

-  DLA  medical  inventory  reduced  61  percent  since  1961 . 

-  Price  reduction  of  25  to35  percent  and  24-hour  response  time. 

—  Sale  of  $560M  in  FY95;  goal  is  $41.2B  in  FY99. 

Results  of  Navy  In-house/Commercial  Competitions  (an  example): 

•  The  Center  for  Naval  Analysis  analyzed  the  results  of  more  than  800  Navy 
competitive  contract  awards  conducted  1978  to  1990  when  in-house  activities 
openly  competed  with  commercial  activities  (in  accord  with  0MB  Circular  A- 
76  guidelines,  hereafter  referred  to  as  A-76).  As  a  result  of  the  competitions, 
both  the  Navy  and  the  outside  vendors  achieved  savings  averaging  20  to  30 
percent.  The  analysis  also  indicates  that  A-76  actions  tended  to  focus  on  rela¬ 
tively  narrow  functions  involving  few  government  employees.  More  than  half 
involved  fewer  than  10  employees;  less  than  10  percent  involved  more  than  55 
workers.  The  data  also  indicates  that  outsourcing  savings  were  highest  when 
vendors  took  over  function  traditionally  performed  by  military  personnel.  In 
such  cases,  the  Navy  realized  savings  of  nearly  50  percent  of  function  cost. 

This  savings  rate  reflects  the  relatively  high  cost  of  military  personnel,  including 
fringe  benefits.  The  analysis  also  revealed  the  impact  of  outsourcing  on  the 
quahty  and  responsiveness  of  support  functions,  and  found  transferring  work¬ 
load  to  outside  vendors  resulted  in  no  significant  quality  problems. 

1.10.6  Impediments 

The  DSB  study,  which  was  initiated  in  October  1995  by  the  USD(A&T),  recorded  that  in 
January  1996,  the  Deputy  Secretary  of  Defense  noted,  ‘The  hardest  things  to  change  are 
institutions  that  have  been  successful  and  need  to  change  anyway.”  DoD  has  been  very 
successful  but  changes  are  needed  to  ensure  that  the  United  States  continues  as  the 
world’s  preeminent  military  power,  which  in  this  case  involves  freeing  funds  for  force 
modernization. 

According  to  the  study,  the  primary  impediments  to  the  implementation  of  an  aggres¬ 
sive  DoD  outsourcing  strategy  include  statutory  restrictions  and  congressional  micro- 
management;  the  time-consuming  and  complicated  nature  of  the  DoD  procurement  proc¬ 
ess;  the  complexity  and  lack  of  equity  in  A-76  pubUc/private  competitions;  the  lack  of 
adequate  government  cost  data  to  support  such  competitions;  DoD  policies  to  preserve  in- 
house  capabilities  to  perform  certain  “core”  maintenance  tasks;  and  the  resistance  of  the 
DoD  culture  to  fundamental  change. 

In  another  area,  acquisition  reform  has  not  fuUy  addressed  the  unique  problems  and  re¬ 
quirements  associated  with  service  contracts.  For  example,  DoD  contracting  officers  fire- 
quently  lack  adequate  expertise  in  the  service  being  procured.  Because  of  this  lack  of 
functional  expertise,  they  often  do  not  have  a  comprehensive  understanding  of  the  contract 
terms  and  conditions  that  are  most  needed  to  be  effective  for  a  particular  service. 
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Moreover,  vendors  report  that  DoD  continues  to  base  vendor  selection  primarily  on 
hourly  labor  rates.  Past  performance,  reputation,  and  reengineering  potential  are  not  gen¬ 
erally  emphasized  in  the  proposal  evaluation  process.  The  DoD  procurement  process  also 
fosters  formalized,  distant,  and  sometimes  adversarial  relationships  between  vendors  and 
DoD  contract  oversight  personnel.  Private  sector  experience  suggests  that  an  interactive, 
more  collaborative  approach  is  key  to  effective  management  of  complex  service  contracts. 
Finally,  in  the  current  environment  there  are  few  incentives  for  the  mihtary  services  to  pur¬ 
sue  an  aggressive  outsourcing  program.  Base  commanders  are  not  evaluated  on  their  ef¬ 
fectiveness  in  outsourcing  support  functions  and,  in  fact,  are  predisposed  to  protect  the 
job  security  of  their  staff.  Moreover,  the  Services  fear  that  savings  achieved  from 
outsourcing  are  likely  to  be  diverted  to  other  functions,  which  is  indeed  the  case  if  funds 
are  to  be  found  for  force  modernization. 

Privatization  presents  serious  problems  for  the  DoD.  These  problems  include  an  unwill¬ 
ingness  on  the  part  of  industry  to  operate  what  was  once  a  government  operated  facility 
with  the  same  number  of  employees  and  with  the  same  compensation  package  previously 
used  by  the  government  doing  the  same  work  effort.  In  addition,  several  statutes  place 
restrictions  on  how  much  DoD  depot-level  workload  can  be  converted  to  the  private  sec¬ 
tor.  The  primary  impediment  is  10  U.S.C.  2469  which  states  that  no  depot  level  workload 
over  $3  million  being  performed  by  a  depot-level  activity  of  the  DoD  may  be  performed  by 
a  contractor  unless  the  Secretary  of  Defense  uses  competitive  procedures  for  the  selection 
of  such  contractor;  and  further,  the  provisions  of  A-76  shall  not  apply  in  this  selection. 

1.10.7  Proposed  Strategy  and  Recommendations 

The  DSB  task  force  report  shows  that  it  is  possible  to  achieve  an  estimated  annual  savings 
of  $7  to  $12  bilhon  from  outsourcing  by  FY02.  The  key  elements  of  an  aggressive  strat¬ 
egy  to  achieve  this  goal  foUow:  (1)  outsourcing  aU  support  functions  that  can  be  per¬ 
formed  cheaper  and/or  more  effectively  by  the  private  sector;  (2)  reducing  emphasis  on 
A-76  pubhc/private  competition,  i.e.,  accept  that  A-76  is  seriously  flawed  and  discourages 
outsourcing;  (3)  taking  full  advantage  of  A-76  waivers  and  exemptions;  (4)  focusing  on 
military  billets;  (5)  eliminating  statutory  and  institutional  impediments;  and  (6)  structuring 
an  aggressive  plan  and  holding  senior  managers  accountable. 

Numerous  reconraiendations  are  offered  that  are  DoD-wide  in  nature.  In  October  1996, 
the  USD(A&T)  stated,  “I  believe  we  are  truly  moving  beyond  adherence  to  the  old  con¬ 
ventional  wisdom  that  dictated  that  we  own  all  capabilities  tied  to  support  for  the  war¬ 
fighter.  We  have  selectively  tested  the  effectiveness  and  efficiency  of  outsourcing  various 
logistics  support  functions  and  they  have  been  successful.  Our  immediate  challenge  now 
is  to  move  forward  with  widespread  deployment  of  similar  outsourcing  privatization  ef¬ 
forts  across  a  broad  front.” 


1-16 


1.11  JOINT  VISION  2010 


This  Chairman  of  the  Joint  Chiefs  of  Staff  1996  document  is  a  conceptual  template  for 
how  America’s  Armed  Forces  wiU  channel  the  vitality  and  innovation  of  its  people  and 
leverage  technological  opportunities  to  achieve  new  levels  of  effectiveness  in  joint  war¬ 
fighting.  This  vision  of  future  warfighting  embodies  the  improved  intelligence  and  com¬ 
mand  and  control  available  in  the  information  age  and  goes  on  to  develop  four  operational 
concepts:  (1)  dominant  maneuver,  (2)  precision  engagement,  (3)  full  dimensional  protec¬ 
tion,  and  (4)  focused  logistics. 

In  terms  of  missions,  tasks,  and  strategic  concepts,  Joint  Vision  2010  states  that  the  pri¬ 
mary  task  of  the  armed  forces,  as  noted  above,  will  remain  to  deter  conflict.  But,  should 
deterrence  fail  to  fight  and  win  our  nation’s  wars,  America’s  strategic  nuclear  deterrent, 
along  with  appropriate  national-level  detection  and  defensive  capabihties,  will  likely  re¬ 
main  at  the  core  of  American  national  security.  However,  the  bulk  of  our  Armed  Forces 
will  be  engaged  in  or  training  for  worldwide  military  operations.  In  these  operations,  we 
will  largely  draw  upon  our  conventional  warfighting  capabilities.  We  will  fight  if  we  must; 
but  we  will  also  use  these  same  capabilities  to  deter,  contain  conflict,  fight  and  win,  or 
otherwise  promote  American  interests  and  values. 

In  defining  focused  logistics,  the  vision  statement  notes  that  the  other  three  operational 
concepts  rely  on  our  abihty  to  project  power  with  the  most  capable  forces,  at  the  decisive 
time  and  place.  To  optimize  the  three  non- logistic  concepts,  logistics  must  be  responsive, 
flexible,  and  precise.  Focused  logistics  wiU  be  the  fusion  of  information,  logistics,  and 
transportation  technologies  to  provide  rapid  crisis  response,  to  track  and  shift  assets  even 
while  en  route,  and  to  deUver  tailored  logistics  packages  and  sustainment  directly  at  the 
strategic,  operational,  and  tactical  levels  of  operations.  It  will  be  fully  adaptive  to  the 
needs  of  our  increasingly  dispersed  and  mobile  forces,  providing  support  in  hours  or  days 
versus  weeks.  Focused  logistics  will  enable  joint  forces  of  the  future  to  be  more  mobile, 
versatile,  and  projectable  from  anywhere  in  the  world. 

Logistics  functions  will  incorporate  information  technologies  to  transition  from  the  rigid 
vertical  organizations  of  the  past.  Modular  and  specifically  tailored  combat  service  sup¬ 
port  packages  wiU  evolve  in  response  to  wide-ranging  contingency  requirements.  Service 
and  Defense  agencies  wUl  work  jointly  and  integrate  with  the  civilian  sector,  where  re¬ 
quired,  to  take  advantage  of  advanced  business  practices,  commercial  economies,  and 
global  networks.  Active  and  reserve  combat  service  support  capabilities,  prepared  for 
complete  integration  into  joint  operations,  wiU  provide  logistics  support  and  sustainment 
as  long  as  necessary. 

Information  technologies  wUl  enhance  airlift,  sealift,  and  pre-positioning  capabilities  to 
Ughten  deployment  loads,  assist  pinpoint  logistics  delivery  systems,  and  extend  the  reach 
and  longevity  of  systems  currently  in  the  inventory.  The  combined  impact  of  these  im¬ 
provements  wiU  be  a  smaUer,  more  capable  deployed  force.  It  wUl  require  less  continuous 
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support  with  a  smaller  logistics  footprint,  decreasing  the  vulnerabUity  of  our  logistics  lines 
of  communications. 

1.12  ASSUMPTIONS  ABOUT  THE  FUTURE  LOGISTICS  ENVIRONMENT 

The  following  logistics  assumptions  broadly  represent  intended  courses  of  action  or  per¬ 
ceptions  as  stated  by  various  individuals  in  DoD  leadership  roles;  however,  at  this  time 
(1997)  they  cannot  be  stated  as  fact. 

•  The  focus  will  shift  from  global  to  highly  diverse,  regional  conflicts  —  for 
peacekeeping,  humanitarian,  or  combat  missions  —  and  demand  agile  logistics 
support. 

•  Streamlining  to  a  leaner  logistics  system  can  be  achieved  through  a  tighter  inte¬ 
gration  of  business  and  production  processes. 

•  Mihtary  and  commercial  ships  and  aircraft  available  to  carry  mihtary  equipment 
to  both  improved  and  unimproved  locations  will  continue  to  be  a  con-straint  to 
deploying  forces. 

•  Logistics  information  has  become  a  principal  commodity  of  the  logistics  system. 

•  The  industrial  base,  upon  which  logistics  support  relies,  will  continue  to  experi¬ 
ence  an  overall  reduction  in  defense  logistics-related  work. 

•  DoD  Continuous  Acquisition  Life-Cycle  Support  (CALS)  (see  Chapter  18)  must 
allow  for  the  exchange  of  data/drawings  in  support  of  an  aging  DoD  inventory, 
including  the  few  new  items  entering  the  inventory  over  the  next  decade.  Leg¬ 
acy  data  in  an  automated  form  is  of  paramount  importanee. 

•  System  complexity  wiU  increase;  but  continued  improvements  in  reliability, 
maintainability,  and  deployability,  will  encourage  ehanges  to  traditional  logistics 
concepts. 

•  The  United  States  will  need  to  continue  to  support  its  systems  in  foreign  inven¬ 
tories  while  relying  more  on  offshore  sources. 

•  Petroleum  wiQ  remain  the  major  source  of  mobility  energy;  but  eommitments 
will  increase  to  develop  alternative  clean  fuels. 

•  The  demand  wiU  decrease  for  some  sources  of  conventional  ammunition, 

•  The  DoD  Logistics  Strategic  Plan,  Edition  1996/1997,  pages  6-8,  lists  numer¬ 
ous  additional  logistics  assumptions. 
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1.13  THE  QUADRENNIAL  DEFENSE  REVIEW  —  1997 


The  final  report  from  the  1997  Quadrennial  Defense  Review  (QDR)  was  released  in  May, 
1997.  The  QDR  was  “global”  in  nature  and  examined  not  only  force  size  and  structure 
but  also  force  modernization  and  logistics  support.  The  following  points  were  made  that 
are  relevant  to  the  subject  of  acquisition  logistics: 

•  “A  Revolution  in  Business  Affairs  (RBA)  has  begun.  The  RBA  includes:  re¬ 
ducing  overhead  and  streamlining  infrastructure;  taking  maximum  advantage  of 
acquisition  reform;  outsourcing  and  privatizing  a  wide  range  of  support  activities 
when  the  necessary  competitive  conditions  exist;  leveraging  commercial  tech¬ 
nology,  dual-use  technology,  and  open  systems;  reducing  unneeded  standards 
and  specifications;  utilizing  integrated  process  and  product  development  (IPPD); 
and  increasing  cooperative  development  programs  with  allies.” 

•  The  goals  set  forth  in  Joint  Vision  2010  are  the  foundation  for  a  broader  effort 
to  exploit  the  Revolution  in  Military  Affairs  (RMA).  Focused  logistics  inte¬ 
grates  information  superiority  and  technological  iimovations  to  develop  state-of- 
the-art  logistics  practices  and  doctrine.  This  will  permit  us  to  accurately  track 
and  shift  assets,  even  while  en  route;  thus,  the  delivery  of  tailored  logistics  pack¬ 
ages  and  more  timely  force  sustainment  at  the  strategic,  operational,  and  tactical 
levels  of  operations  will  be  facilitated.  Focused  logistics  will  reduce  the  overall 
size  of  logistics  support  and  help  to  provide  more  agile,  leaner  combat  forces 
that  can  be  rapidly  deplo^'ed  and  sustained  around  the  globe. 

•  “Initiatives  such  as  Joint  Total  Asset  Visibility  and  the  Global  Combat  Support 
System  will  provide  deployable,  automated  supply  and  maintenance  information 
systems  for  leaner,  more  responsive  logistics.” 

•  Initiatives  have  been  adopted  that  will  reduce  Defense  agency  and  Defense-wide 
infi’astructure  persoimel  and  costs.  Among  these  are  plans  to  outsource  selected 
Defense  Logistics  Agency  functions,  including  cataloging  and  increasing  compe¬ 
tition  for  disposal  and  physical  distribution. 

•  Within  the  military  departments,  initiatives  are  being  reviewed  to: 

—  Reduce  logistics  support  costs  by  integrating  organizations  and  functions 
(supply,  financial,  automated  data  processing,  transportation,  maintenance, 
and  procurement)  that  are  now  being  performed  at  multiple  locations  into  a 
common  geographic  area  and  by  eliminating  redundant  facilities  and  opera¬ 
tions. 

—  Compete,  outsource,  or  privatize  military  department  infrastructure  func¬ 
tions  that  are  closely  related  to  commercial  enterprises.  Most  of  these  ac¬ 
tions  involve  logistics  and  installation  support  functions. 
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1.14  A  FEW  OBSERVATIONS 


A  number  of  trends,  which  significantly  impact  the  character  and  management  of  the 
logistics  support  function,  have  emerged  over  the  past  three  decades.  Some  of  these 
trends  (shown  in  figure  1-1)  involve  changes  in  aircraft  fleet  sizes,  sorties  per  aircraft, 
radar  reliability,  the  length  of  the  technology  cycle,  the  character  of  Defense  Department 
technology,  and  the  size  of  the  defense  industrial  base.  They  are  representative  of  changes 
throughout  the  U.S.  arsenal  of  weapon  systems. 


LOGISTICS  EVOLUTION 
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Good  Old  Days 
1960s  — 1980s 

Now 

1990s  — 2000s 

Fleet  Sizes 

Sorties 

Reliability 

Technology  Cycle 
Defense  Technology 
Industrial  Base 

Thousands 

1-2  per  day 
<10  hr  F-4  Radar 
Slow  -  Years 
Leading  Edge 
Defense  -  Big 

Hundreds 

3  -  4  per  day 
>100  hr  F-16  Radar 

Fast  -  Months 

Following  Edge 

Defense  -  2% 

Figure  1-1:  Logistics  Evolution 


In  the  following  paragraphs,  the  candid  and  sometimes  terse  comments  and  observations, 
offered  in  1995  and  1996  by  several  senior  DoD  leaders,  are  summarized.  They  set  a 
tone,  albeit  unofficial,  for  this  guide.  These  comments  are  offered  in  the  context  of  the 
5(X)0-series  directives  and  other  DoD  policy  statements;  and  they  urge  tailoring,  innova¬ 
tion,  and  risk-taking  in  program  management. 

The  current  DoD  logistics  system  is  too  close  to  a  “just-in-case”  system  with  little  or  no 
in-transit  asset  visibihty  and  a  lack  of  a  fast,  responsive  distribution.  This  system  is  in  stark 
contrast  to  the  “just-in-time”  systems  being  implemented  by  commercial  enterprises  and 
our  own  industrial  partners.  Neither  the  “just-in-case”  nor  “the  just-in-time”  system  are 
right  for  the  Defense  Department.  A  tailored  approach  that  is  close  to  a  lean  “just-in- 
time”  system  is  needed.  Reducing  cycle  times  is  all-important!  Further,  our  logistics  will 
never  be  structured  properly  until  full  information  systems  are  available  to  provide  total 
asset  visibility.  Our  support  base  is  too  costly.  Based  on  questioning  by  senior  leaders,  it 
is  clear  that  PMs  do  not  know  the  nature  of  support  cost  for  their  programs.  We  need 
better  models  to  understand  the  “cost  base”  of  our  programs.  DoD  should  look  to  the 
commercial  world  to  see  how  products  are  supported.  Airlines  used  to  be  like  DoD  is 
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today.  Now  they  have  a  small  support  base  and  look  to  the  manufacturer  for  support. 
Much  room  exists  for  innovative  thinking  in  logistics.  DoD  is  accustomed  to  periodic  big 
buys  that  are  warehoused  and  then  distributed.  Instead,  we  need  to  move  to  catalogue 
buying  for  overnight  delivery,  which  is  now  being  used  in  a  few  cases  for  mess  haU  meals, 
uniforms,  lumber,  steel,  and  support  of  some  medical  facilities. 

Other  observations  include  comments  on  the  Single  Process  Initiative  (SPI),  which  needs 
to  be  applied  in  our  contracts.  Progress  thus  far  has  all  been  in  the  area  of  quality  and 
manufacturing.  We  need  an  SPI  focus  in  the  area  of  business  practices,  i.e.,  financial  man¬ 
agement,  RPPs,  and  proposals.  First-  and  second-tier  subs  and  base-level  DoD  people  are 
not  adequately  aware  of,  nor  do  they  fuUy  use,  SPI.  Relative  to  solicitations  and  propos¬ 
als,  every  effort  should  be  made  to  keep  the  cost  down  to  both  government,  on  prepara¬ 
tion,  source  selection,  and  award,  and  to  industry  on  responses  to  RFPs.  In  this  regard, 
several  new  and  innovative  ideas  developed,  including  the  use  of  constrained  written  pro¬ 
posals  as  a  preview  document  for  the  government.  This  preview  document  is  offered  prior 
to  a  contractor’s  official  oral  presentation  of  its  proposal  and  demos  and,  if  applicable, 
with  the  cost  proposals  following.  Demos  can  be  costly  for  a  contractor;  therefore,  con¬ 
sideration  can  be  given  to  taping  the  presentations  for  subsequent  reviews.  Prior  to  RFP 
release,  contractors  should  be  interviewed  and  encouraged  to  share  all  the  information  the 
law  allows.  Thus,  only  qualified  contractors  will  participate;  and  both  parties  will  not 
waste  resources.  The  contract  community  fails  to  understand  what  the  new  law  authorizes 
them  to  do  in  the  context  of  increased  freedom. 

The  acquisition  community  must  grasp  interoperability  in  the  same  context  as  does  the 
user.  Common  architecture  and  open  communications  are  key.  Contract  Data  Require¬ 
ments  Lists  (CDRLs)  are  sometimes  nearly  useless.  Get  agreements  with  contractors  on 
CDRL  type  tasks.  Big  incentives  are  a  good  government  management  tool  and  necessary 
in  today’s  world.  PMs  need  to  understand  industry’s  financial  incentives.  The  operational 
Requirements  Document  (ORD)  is  where  industry  is  going  to  look  for  an  understanding  of 
requirements.  However,  have  the  user  talk  to  the  contractor  rather  than  just  read  the 
ORD.  Be  in  a  position  to  teU  the  contractor  that  if  he  fails  to  perform,  he  will  be  replaced. 
Use  Commercial/Nondevelopmental  Item  (NDI)  for  modification  programs  that  will  be 
around  for  only  10  years  or  less.  Program  managers  must  make  IPT  people  accountable. 
IPTs  tend  to  break  down  fiefdoms.  The  release  of  an  item  to  a  foreign  government  must 
be  worked  out  very  early  in  a  program,  or  Foreign  Military  Sales  (FMS)  money  will  be 
lost  to  the  program.  On  Commercial/NDI,  if  you  strip  away  military  layers  you  will  find  a 
commercial  system  underneath;  but  you  may  also  find  old  technology.  Thus,  will  a  new 
system  really  save  a  user  costs?  Money  is  the  one  big  problem  for  all  PMs. 

In  the  eyes  of  DoD  senior  leadership,  many  of  the  tools  needed  by  logistics  managers  in¬ 
volve  change;  they  include: 

•  Change  in  program  funding  thresholds  related  to  moving  dollars  (DoD  rules  not 
laws). 
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•  Better  use  of  modeling  and  simulation  so  all  requirements  can  be  more  com¬ 
pletely  considered. 

•  Better  LCC  models  with  people  trained  to  use  them. 

•  Better  application  of  commercial  technology  and  production  methods.  Copy  in¬ 
dustry’s  ways.  They  are  not  perfect  but  they  know  how  to  cut  cycle  times.  In¬ 
dustry  has  the  data  when  they  need  it  to  perform  such  tasks. 

•  Emplojment  of  commercial  support  for  contingencies.  The  Civil  Reserve  Air 
Fleet  (CRAF)  aircraft  program  is  a  good  example  of  where  DoD  has  kept  a 
“core”  capability  but  has  used  commercial  resources. 

•  Use  of  allies.  This  is  important  because:  (1)  our  forces  are  not  alone  anywhere 
in  the  world,  (2)  it  is  politically  strengthening,  and  (3)  costs  are  shared  and  off¬ 
sets  need  to  be  adequate.  Congressional  legislation,  which  may  give  the  Secre¬ 
tary  of  Defense  waiver  authority  on  “Buy  American,”  is  in  progress. 

1.15  REDUCING  LOGISTICS  CYCLE  TIMES 

Reducing  logistics  cycle  times  is  one  of  the  three  major  goals  stated  in  the  DoD  Logistics 
Strategic  Plan  (1996/1997).  The  plan  states  that,  ‘Time  is  the  enemy  of  logistics.  Each 
day  of  delayed  response  to  the  user  represents  millions  of  dollars  in  inventories  waiting  to 
be  moved,  repaired,  delivered,  stowed  and  used.  Slow  cycle  times:  (1)  are  symptomatic 
of  processes  that  need  to  be  improved,  eliminated,  or  outsourced  to  high  quality  providers; 
(2) ...  reflect  gaps  in  required  management  information. ...  and  (3) ...  are  caused  by  stan¬ 
dards  that  do  not  challenge  logistics  managers  ...”  The  plan  goes  on  to  state:  ‘The  best 
private  sector  practitioners  of  logistics  have  distinctly  moved  towards  reducing  cycle 
times.  Customers  demand  quicker  and  more  reliable  response  —  whether  they  are  manu¬ 
facturers  seeking  to  minimize  holdings  of  parts  and  assemblies,  or  typical  consumers  buy¬ 
ing  merchandise  from  catalogue  sales  outlets.”  Rapid  response  capability  is  essential  for: 

•  supporting  a  mobile  force; 

•  responding  to  multiple  contingencies; 

•  responding  with  the  most  current  knowledge  of  operational  requirements; 

•  minimizing  investment  —  either  in  materiel  or  repair  work  —  that  can  become 
obsolete  or  that  is  not  immediately  relevant  to  mission  needs; 

•  reducing  investment  in  facilities  and  related  infrastructure;  and 

•  increasing  customer  confidence. 
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1.15.1  Reduce  Logistics  Response  Time 

The  previously  noted  plan  states  that  quality  support  for  a  smaller,  more  mobile  force  with 
a  smaller  logistics  infrastructure  requires  a  major  shift  towards  customer  needs  and  cus¬ 
tomer  measures  of  logistics  system  performance.  Slow  response  times,  for  example,  drive 
the  need  for  increased  inventory  levels  and  undermine  the  customers’  confidence  in  the 
supply  system.  The  plan  describes  a  response  time  “goal”  as,  “By  September  1997,  reduce 
average  logistics  response  times  by  one-third  from  a  baseline  based  on  a  first  quarter  FY 
96  average.  By  October  2001,  reduce  the  average  age  for  backordered  items  to  30  days.” 
In  the  first  case,  this  would  be  from  24  to  16  days  for  aU  of  DoD.  Transportation  is  a 
major  element  of  logistics  response  time.  The  other  elements  include  time  required  to 
submit,  receive,  and  process  a  requisition;  picking  the  supply  items;  packaging  them  for 
shipment;  holding  for  transportation;  and  receiving  and  distributing  the  requisitioned 
items. 

1.15.1.1  Transportation.  A  review  of  a  major  segment  of  the  transportation  element  may 
provide  some  insight  into  the  response  time  issue.  In  FY94,  the  Defense  Logistics 
Agency’s  (DLA)  Continental  United  States  (CONUS)  freight  shipments  totaled  approxi¬ 
mately  3,413  million  pounds  and  incurred  $178,350,000  in  transportation  charges  for  rail, 
truckload,  less  than  truckload  (LTL),  small  package  -  surface,  small  package  -  air,  and  air 
freight  services.  Nearly  90  percent  of  those  shipments  were  moved  as  small  packages  or 
airfreight;  but  raU,  truckload,  and  LTL  shipments  accounted  for  more  than  95  percent  of 
the  weight  and  approximately  80  percent  of  the  cost.  Since  nearly  90  percent  of  DLA’s 
shipments  are  transported  by  small  package  or  air  freight  carriers  and  the  majority  of  those 
shipments  move  less  than  900  miles,  DLA’s  transit  times  are  typically  three  days  or  less. 

When  benchmarking  DoD’s  standards  for  transit  times  with  those  of  commercial  industry, 
the  Logistics  Management  Institute  (LMI)  found  that  the  latter  were  often  more  stringent. 
As  an  example,  comparing  industry  state- to-state  transit  time  standards  with  those  speci¬ 
fied  in  government  guaranteed  traffic  (GT)  agreements,  48  percent  of  the  commercial  LTL 
transit  time  standards  range  from  one  to  four  days  better  (i.e.,  shorter)  than  the  corre¬ 
sponding  GT  standards.  Further,  69  percent  of  the  commercial  truckload  standards  range 
from  one  to  three  days  better  than  the  corresponding  GT  standards.  Not  only  are  many 
commercial  standards  shorter  than  DoD’s,  but  they  are  continuously  improving  because  of 
the  competition  among  carriers  in  the  commercial  marketplace. 

The  comparison  of  standards  suggests  that,  when  industry  standards  are  better  than  DoD 
standards,  DoD  should  be  able  to  systematically  reduce  many  of  its  transit  times  at  no  ad¬ 
ditional  cost  by  incorporating  industry  state-to-state  transit  time  standards  into  both  GT 
agreements  and  the  Defense  Traffic  Management  Regulations.  This  brings  us  back  to  best 
commercial  practices.  This  suggests  that  DoD  may  want  to  explore  awarding  GT  agree¬ 
ments  on  the  basis  of  best  overall  value  to  DoD,  not  just  on  the  bid  price.  Consequently, 
LMI  recommended  that  the  Military  Traffic  Management  Command  and  DLA  develop  a 
best-value  GT  agreement  that  requires  carriers  to  propose  both  rates  and  transit  times  for 
DoD  consideration.  Nearly  90  percent  of  DLA’s  shipments  are  moving  by  premium 
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transportation  with  most  experiencing  transit  times  of  three  days  or  less.  Nonetheless, 
they  support  the  position  of  the  USD(A&T)  in  saying  that  further  improvements  are  pos¬ 
sible. 

1.15.2  Summary 

•  Use  of  technology  can  decrease  cycle  time. 

•  Budget  constraints  are  forcing  changes  toward  a  leaner,  more  efficient  logistics  re¬ 
sponse  structure. 

•  Much  can  be  learned  from  the  commercial  world,  where  competitive  pressures  have 
led  to  innovative  procedures  to  reduce  logistics  response  time. 
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2 

WHAT  IS  LOGISTICS? 


Logistics:  Getting  the  Right  Thing  to  the  Right  Place  at  the  Right  Time. 


2.1  CURRENT  DEFINITIONS 

Swiss  Baron  Antoine  Henry  Jomini,  in  his  1838  Summary  of  the  Art  of  War,  made  the 
first  significant  use  of  the  term  "logistics"  by  defining  it  as  the  practical  art  of  moving 
armies.  Admiral  Henry  Eccles,  in  his  1959  book,  Logistics  in  the  National  Defense, 
states  that  the  word  "logistics"  is  an  abstraction  like  the  other  abstractions  of  "strategy, 
tactics,  economics,  or  politics."  Thus,  logistics  is  not  susceptible  to  a  single,  simple,  and 
permanent  definition.  It  is  a  broad  field  of  endeavor  consisting  of  many  interdisciplinary 
activities ...  that,  when  applied  together,  constitute  the  art  and  science  of  logistics.  John 
Mosher  adds  that  logistics  is  an  ancient  art  and  an  emerging  science. 

The  International  Society  of  Logistics  Engineers  (SOLE)  states  that  the  word  "logistics" 
comes  from  the  Greek  word  that  deals  with  mathematical  calculations,  while  its  French 
usage  relates  to  the  supplying,  quartering,  and  movement  of  troops.  The  United  States 
gave  the  word  a  much  broader  definition,  that  of  total  support  of  a  product  during  its 
system  life  cycle.  SOLE  goes  further  to  define  logistics  as  "the  art  and  science  of  man¬ 
agement,  engineering,  and  technical  activities  concerned  with  requirements,  design,  and 
supplying  and  maintaining  resources  to  support  objectives,  plans  and  operations." 

Carl  Henn,  in  the  “SOLE  Member's  Handbook,”  further  defines  logistics  as  "...  the  inte¬ 
grated  design,  management  and  operation  of  physical,  human,  financial  and  information 
resources  over  the  lifetime  of  a  product,  system,  or  service.  In  economic  terms,  it  creates 
time  and  place  utility  in  contrast  to  form  utility  ..." 

John  Mosher  observes  that  logistics  is  a  broad  field  of  endeavor  consisting  of  many  in- 
terdisciphnary  activities;  but  to  be  characterized  as  logistics,  these  and  other  related 
functions/activities  must  be  performed,  managed,  and  organized  as  integrated  systems 
and  subsystems.  He  observes  that  the  depth  of  knowledge  imphed  for  the  professional 
personnel  involved  (in  logistics)  is  considerable.  He  states  that  it  is  certainly  more  than 
one  could  reasonably  expect  to  find  within  a  single  individual  and  that  the  necessary 
systems  viewpoint  (with  proper  attention  to  details)  suggests  a  team  composed  of  experts. 
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2.2  STRATEGIC  LOGISTICS 


Strategic  Logistics  is  perhaps  the  most  unexplored  area  of  logistics  —  the  term  doesn't 
even  appear  in  Brimer  &  Livermore's  Encyclopedia  of  Logistics  Terms.  Martin  Binkin, 
in  Support  Costs  in  the  Defense  Budget,  observes  that  defense  support  is  one  of  the  least 
understood  parts  of  the  defense  program;  and  its  precise  relationship  to  national  security 
has  not  been  defined.  Carter  &  Merritt,  in  Chapter  1  of  Mobilization  and  the  National 
Defense,  state  that  no  recognizable  core  of  primary  literature  exists  which  defines  the 
scope  and  depth  of  mobihzation  concerns.  They  also  describe  existing  hterature  as  being 
a  disjointed,  fragmented,  and  piecemeal  collection.  The  Defense  Secretary's  Commission 
on  Base  Realignments  and  Closures,  reports  that  an  ad  hoc  commission  should  not  be¬ 
come  a  routine  means  for  addressing  subjects  that  are  a  part  of  the  day-to-day  business  of 
governing.  The  Commission  recommended  that  an  ongoing  base-management  process 
be  established  —  clearly  an  area  of  strategic  logistics. 

The  Joint  Chiefs  of  Staff  have  recognized  the  importance  of  strategic  logistics  and,  in 
their  proposed  final  publication  of  the  Basic  National  Defense  Doctrine  (Joint  Pub  0-1 ), 
they  define  strategic  logistics  (in  the  general  sense)  as  the  art  and  science  of  harnessing 
the  economic  and  societal  strengths  of  a  nation  for  national  defense.  In  the  specific 
sense,  strategic  logistics  is  the  process  of  planning  for,  coordinating,  and  allocating  the 
manpower,  materiel,  infrastructure,  and  services  required  for  military  needs,  war  produc¬ 
tion  needs,  and  civil  sector  needs.  It  requires  coordination  between  the  executive  and 
legislative  branches,  state  governments,  and  industry.  Force  generation  and  mobihzation 
are  inclusive  components  of  strategic  logistics.  Figure  2-1  portrays  the  division  between 
strategic  logistics  and  appUed  logistics. 

Several  years  ago,  the  Air  Force  Association  observed,  in  Lifeline  in  Danger:  An  A^- 
sessment  of  the  United  States  Defense  Industrial  Base,  that  the  number  of  firms  doing 
defense  work,  especially  at  the  suppUer  and  subcontractor  levels,  has  been  declining  for 
decades  and  has  had  a  most  harmful  effect  on  the  nation's  defense  posture.  Thus,  do¬ 
mestic  industry  has  difficulty  in  meeting  peacetime,  let  alone  wartime,  defense  needs. 

Von  Clausewitz,  in  On  War,  states  the  importance  of  knowing  the  enemies’  means  and 
potential  of  waging  war  (the  prevaihng  conditions  of  the  state)  —  their  cash  reserves, 
treasury  and  credit,  as  well  as  the  size  of  their  fighting  forces.  In  Sun  Tsu’s  Sixth  Cen¬ 
tury  BC  book,  repubUshed  as  The  Art  of  War,  he  observed  that  national  unity  was  an  es¬ 
sential  requirement  of  victorious  war;  but  he  cautioned  against  conducting  a  protracted 
war,  since  the  resources  of  the  state  would  not  suffice  when  the  army  engaged  in  pro¬ 
tracted  campaigns.  He  observed  that  those  who  were  adept  in  waging  war  do  not  require 
a  second  levy  of  conscripts;  nor  did  they  require  more  than  one  provisioning. 

Writers  have  postulated  that  strategic  logistics,  in  the  commercial  sense,  will  achieve 
greater  future  importance  than  strategic  logistics,  in  the  miUtary  sense.  Richard  Rose- 
crance,  in  The  Rise  of  the  Trading  State,  contends  that  nations  are  becoming  so 
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Figure  2-1:  Tiered  Logistics  Definition 


economically  interdependent  as  to  lessen  their  tendency  to  fight  one  another.  Trade,  not 
military  might,  is  now  the  path  to  world  power.  If  the  real  battlefield  of  tomorrow  is  the 
global  economy,  then  strategic  logistics  —  the  industrial  base  and  resources  of  a  country 
(both  military  &  civilian  productive  capacity)  —  is  of  primary  importance  to  our  national 
security  and  greater  attention  is  warranted. 

Alvin  and  Heidi  Toffler,  in  War  and  Anti-War,  take  an  opposite  view  and  contend  that 
geo-economic  conflict  will  never  be  a  substitute  for  war;  it  is  often  a  prelude  or  provoca¬ 
tion  to  actual  war.  Wars  have  resulted  from  irrationality,  miscalculation,  xenophobia, 
fanaticism,  and  religious  extremism  when  every  "rational"  economic  indicator  suggested 
that  peace  was  preferable. 

2.3  APPLIED  LOGISTICS 


■Tim  Jones,  in  the  first  edition  of  his  Integrated  Logistics  Support  Handbook,  captures  the 
essence  of  applied  logistics  by  dividing  it  into  two  phases.  Phase  1  (commonly  referred 
to  as  acquisition  logistics  or  logistics  engineering)  includes  everything  that  is  done  to 
plan  and  acquire  support  before  a  system  is  delivered  to  the  user.  Phase  2  (commonly 
referred  to  as  tactical/operational  logistics  or  product  support)  includes  the  things  that  are 
done  to  support  the  system  while  it  is  being  used.  He  notes  that  actions  that  occur  during 
Phase  1  dictate  how  well  the  system  will  be  supported  during  Phase  2. 
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2.3.1  Acquisition  Logistics  &  Logistics  Engineering 

Acquisition  logistics  or  logistics  engineering  primarily  occurs  before  the  system  enters 
the  use  phase  and  is  placed  in  the  hands  of  the  customer.  (Modifications  and  product  im¬ 
provements  extend  the  time  frame  of  acquisition  logistics.)  Tactical/operational  logistics 
commences  when  the  customer  starts  to  use  the  system. 

For  contemporary  systems,  acquisition  logistics,  or  logistics,  engineering  never  really 
goes  away  —  especially  for  a  modem  system.  In  “America's  High  Noon  Complex,” 
pubUshed  in  the  Sep-Oct  '94  Army  RD&A  Bulletin,  Norman  Augustine  described  the 
situation  the  best.  He  observed  that  our  military  hardware  is  now  on  a  replacement  cycle 
of  about  54  years  and  that  world  technology  typically  has  a  half-hfe  of  from  2  to  10 
years.  Thus,  system/subsystem  modifications,  changes,  improvements,  and  the  like  con¬ 
stitute  the  norm  for  mihtary  systems  that  may  see  service  lives  in  excess  of  50  years. 

Although  some  commercial  systems  (such  as  the  DC-3  aircraft,  with  a  service  life  in  ex¬ 
cess  of  50  years,  or  the  San  Salvador  Island  lighthouse,  with  a  service  hfe  in  excess  of 
100  years)  may  see  extended  service  lives,  this  is  usually  not  widespread.  Conunercial 
customers  are  more  prone  to  replace/upgrade  their  systems,  and  commercial  manufactur¬ 
ers  are  more  prone  to  facihtate  system  replacements  or  upgrades.  The  "new  and  im¬ 
proved"  product,  the  "newest  and  latest"  model,  and  the  "all  new"  model  are  typical 
commercial  terms  that  behe  this  phenomenon.  Longevity,  however,  still  remains  the 
bellwether  of  a  good  design. 

The  acquisition  logistics/logistics  engineering  function  serves  as  the  advocate  for  the 
most  supportable  design  from  among  the  feasible  design  alternatives.  These  functions 
are  summarized  as  follows: 

IDENTIFYING  the  Operational  Requirements  Document  (ORD)  logistics  con¬ 
straints  and  defining  the  resultant  logistics  support  requirements  (relative  to  each 
support  element)  for  each  proposed  design  alternative  (while  the  alternative  exists 
only  on  paper)  is  a  most  difficult  job.  It  requires  analytical/engineering  skiUs  and 
the  abihty  to  communicate  in  the  language  of  the  design  engineer. 

ADVOCATING  the  selection  of  the  most  easily  supported  design  alternative  in¬ 
volves  conununicating  the  logistics  support  imphcations  of  each  design  alterna¬ 
tive  to  the  other  members  of  the  Integrated  Product  Team  (IPT). 

INFLUENCING  the  emergence  of  this  design  creates  cost-effective/supportable 
detailed  design  decisions. 

REFINING  the  logistics  support  requirements  (relative  to  each  element)  to  reflect 
the  particulars  of  the  emerging  design  involves  ensuring  that  the  logistics  support 
requirements  are  defined  to  the  same  depth  and  at  the  same  pace  as  the  emerging 
design. 
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TESTING  &  EVALUATING,  based  on  this  real-time  definition,  is  a  function 
that  involves  planning  logistics  support  for  the  product/system  during  develop¬ 
mental/engineering  tests  and  during  all  early  field/operational  tests.  Successful 
tests  will  validate  the  workability  of  the  planned  support. 

ACQUIRING  all  necessary  items  of  support  involves  ensuring  that  the  system 
definition  and  procurement  includes  both  the  system/product/service  and  all  req¬ 
uisite  items  of  support  for  each  element.  Producing  the  system  and  its  requisite 
support  items  (in  quantity)  is  a  necessary  follow-up.  The  real  common  interest  of 
the  manufacturing  and  logistics  communities  is  producing  a  quality  product  that 
conforms  to  the  design  through  the  reduction  of  variability  in  the  manufactured 
design.  The  reduction  of  variabiUty  leads  to  products  that  perform  better  during 
the  use  phase  and  require  less  maintenance  because  they  break  down  less.  Thus, 
the  manufacturing  and  logistics  communities  have  a  strong,  common  area  of  in¬ 
terest. 

PROVIDING  the  system  to  the  customers  in  the  right  place,  at  the  right  time,  and 
in  the  right  quantities  is  done  through  the  execution  of  a  good  support  plan  and/or 
a  first-rate  fielding  plan. 

IMPROVING  the  system  through  the  inevitable  change/modification  process  is 
another  important  function. 

These  functions  represent  the  core  activities  of  an  acquisition  logistics  member  of  an  In¬ 
tegrated  Product  Team  (IPT),  and  they  are  reiterated  in  Figure  2-2.  Note  that  the  execu¬ 
tion  of  a  modification  program  after  the  system  has  been  produced  requires  each  acquisi¬ 
tion  logisticsAogistics  engineering  function  to  be  repeated.  Thus,  acquisition  logis¬ 
tics/logistics  engineering  (in  a  world  of  rapidly  changing  technology)  never  really  goes 
away. 

2.3.2  Tactical/Operational  Logistics  &  Product  Support 

Tactical/Operational  Logistics  is  perhaps  the  oldest  area  of  logistics.  Van  Creveld,  in 
Supplying  War,  defines  logistics  as  "the  practical  art  of  moving  armies  and  keeping  them 
supplied."  He  further  observes  that  logistics,  an  admittedly  unexciting  aspect  of  war, 
makes  up  as  much  as  nine-tenths  of  the  business  of  war. 

Kenneth  Brown  in  his  National  Seeurity  Essay,  Strategies:  the  Logistics-Strategy  Link, 
addresses  the  "classic"  definition  of  this  area  of  logistics  as  commonly  associated  with 
the  tail  of  the  metaphorical  beast  that  represents  the  forces  with  which  we  wage  war. 
Furthermore,  the  tooth-to-tail  comparison  usually  contends  that  more  teeth  and  less  tail 
always  makes  for  a  better  "fighting  animal." 
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Figure  2-2:  Acquisition  Logistics  Functions 


The  Joint  Chiefs  of  Staff,  in  their  proposed  final  pubhcation  of  the  Basic  National  De¬ 
fense  Doctrine  (Joint  Pub  0-1 ),  take  a  classically  military  viewpoint  and  define  logistics 
as  the  science  of  planning  and  carrying  out  the  movement  and  maintenance  of  forces. 

Ben  Blanchard,  in  Logistics  Engineering  and  Management,  addresses  product  support  in 
the  commercial  sector  to  include  such  activities  as  material  flow,  product  distribution, 
transportation,  warehousing,  and  the  like.  His  more  general  definition,  in  Systems  Engi¬ 
neering  and  Analysis,  is  well-suited  to  defining  product  support  as  the  composite  of  all 
considerations  needed  to  assure  the  effective  and  economic  support  of  a  system  through¬ 
out  its  programmed  life  cycle. 

Most  modem  manufacturers  of  durable  goods  realize  the  importance  of  a  responsive 
product  support  organization  and  the  cost  of  a  dissatisfied  customer.  The  goal  of  pro¬ 
viding  excellent  performance  or  at  least  satisfactory  use  in  service  remains.  Interest  in 
this  area  is  currently  intense. 

2.4  IMPLICATIONS 

Acquisition  Logistics,  at  its  best,  requires  a  "problem  prevention"  mentality.  Operational 
logistics,  on  the  other  hand,  generally  needs  a  "problem  solving"  mentality.  Strategic 
logistics  generally  requires  a  "strategic  thinking"  mentality  —  someone  who  sees  the 
"broadest  picture." 
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In  the  introduction  to  the  1917  publication,  Pure  Logistics,  Stanley  Falk  stated  that  the 
word  “logistics”  has  been  in  use  in  the  United  States  for  more  than  a  century.  For  most 
of  this  period,  people  have  had  difficulty  in  agreeing  on  its  precise  definition.  Even  to¬ 
day,  the  meaning  of  logistics  is  somewhat  inexact.  In  the  same  book,  Lt  Col  George 
Thorpe  argued  that  a  proper  definition  {of  logistics}  was  essential  for  understanding  the 
true  role  and  function  of  logistics,  for  ensuring  that  none  of  its  aspects  were  neglected, 
and  for  achieving  ultimate  victory  in  any  conflict. 

Heskett,  Glaskowsky  and  Ivie,  in  Business  Logistics:  Physical  Distribution  and  Materials 
Management,  observe  that  the  use  of  clearly  defined  terms  can  provide  time  savings;  but 
it  has  taken  marketing  and  production  scholars  and  executives  six  decades  to  organize 
their  terminology  in  a  usable,  time-saving,  and  almost  universally  understandable  form. 
Jomini  introduced  the  term  "logistics"  in  1838.  The  time  has  come  to  seek  a  universal 
definition  of  logistics. 
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3 

DEPARTMENT  OF  DEFENSE 
ACQUISITION  POLICY 

Successful  acquisition  programs  are  fundamentally  dependent  upon 
competent  people,  rational  priorities,  and  clearly  defined  responsibilities. 

DoDD  5000.1 


3.1  REQUIREMENTS 

3.1.1  Authority  and  Methodology 

Department  of  Defense  Directive  5000.1,  of  15  March  1996,  Subject:  Defense  Acquisi¬ 
tion,  in  accordance  with  Office  of  Management  and  Budget  (OMB)  Circular  A- 109,  es¬ 
tablishes  a  disciplined,  yet  flexible,  management  approach  for  acquiring  quality  products 
that  satisfy  the  operational  user's  requirements.  Such  an  approach  must  effectively  trans¬ 
late  operational  needs  into  stable,  affordable  acquisition  programs.  The  policies  stated  in 
DoDD  5000.1  apply  to  all  elements  in  DoD  and  are  intended  to  forge  a  close  and  effective 
interface  among  the  Department's  three  principal  decision  support  systems,  which  are  the: 

•  Requirements  Generation  System, 

•  Acquisition  Management  System,  and  the 

•  Planning,  Programming,  and  Budgeting  System. 

Within  the  Acquisition  Management  System,  all  the  tasks  and  activities  needed  to  bring  a 
program  to  the  next  major  milestone  oeeur  during  an  acquisition  phase.  Phases  provide  a 
logical  means  of  progressively  translating  broadly  stated  mission  needs  into  well-defined, 
system-specific  requirements  and  ultimately  into  operationally  effective,  suitable,  and  sur- 
vivable  systems.  These  systems  are  also  intended  to  provide  the  operational  user  with 
measurable  improvements  to  mission  accomplishment  in  a  timely  manner  and  at  a  fair  and 
reasonable  price.  As  previously  noted,  the  applicable  policies  and  principles  that  govern 
the  operation  of  the  defense  acquisition  system  and  guide  all  defense  acquisition  programs 
are  stated  in  DoDD  5000.1  and  are  divided  into  the  three  major  policy  areas  that  follow: 

•  Translating  Operational  Needs  into  Stable,  Affordable  Programs; 

•  Acquiring  Quality  Products;  and 

•  Organizing  for  Efficiency  and  Effectiveness. 
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3.1.2  Major  Themes 


•  Teamwork.  The  employment  of  Integrated  Product  Teams  (IPTs),  in  an  envi¬ 
ronment  encouraging  Integrated  Product  and  Process  Development  (IPPD),  is 
strongly  emphasized  in  DoD  5000.2-R.  Chapter  4  of  this  Guide  is  devoted  to 
this  topic. 

•  Tailoring.  As  in  the  past,  all  programs  must  accompUsh  certain  core  activities. 
However,  acquisition  personnel  are  now  encouraged  to  tailor  the  acquisition 
process  and  streamline  the  reporting  and  documentation  process  in  accord  with 
common  sense  and  sound  business  management  practice.  The  few  reports  and 
report  formats  dictated  by  the  new  DoD  5000.2-R  are  those  described  in  Ap¬ 
pendices  I-IV  of  that  regulation. 

•  Empowerment.  DoDD  5000. 1  and  DoD  5000.2-R  reflect  current  efforts  to 
empower  program  management  personnel  and  their  vendors  to  do  the  best  they 
can.  Those  documents  canceled  many  directives  that  previously  dictated  rigid 
actions  and  reporting  requirements.  Program  Managers  (PMs)  do  not  have  to 
ask  permission  to  take  actions  that  are  otherwise  permitted  by  law  and  are 
within  the  scope  of  their  charters. 

•  Cost  As  an  Independent  Variable  (CAIV).  Henceforth,  acquisition  managers 
and  their  respective  weapons  system  user  representatives  must  consider  both 
performance  requirements  and  fiscal  constraints.  Responsible  cost  objectives 
must  be  set  for  each  program  phase.  Chapter  14  is  devoted  to  this  topic. 

•  Commercial  Products.  The  new  directives  mandate  that  DoD  fuUy  implements 
the  statutory  preference  for  the  acquisition  of  commercial  items  by  federal 
agencies.  Acquisition  of  commercial  items,  components,  processes,  and  prac¬ 
tices  provides  rapid  and  affordable  application  of  fast-paced  commercial  tech¬ 
nologies  to  vahdated  DoD  mission  needs. 

•  Best  Practices.  Acquisitions  of  the  future  must  take  into  account  customary 
commercial  practices  in  developing  acquisition  strategies  and  contracting  ar¬ 
rangements. 

3.1.3  Key  Officials  and  Forums 

Program  definition  is  the  process  of  translating  broadly  stated  mission  needs  into  a  set  of 
operational  requirements  from  which  specific  performance  specifications  are  derived.  In 
the  area  of  requirements,  a  key  official  is  the  Vice-Chairman  of  the  Joint  Chiefs  of  Staff 
(VCJCS).  The  key  forum  is  the  Joint  Requirements  Oversight  Council  (JROC),  chaired  by 
the  VCJCS.  The  JROC,  in  the  case  of  Acquisition  Category  (ACAT)  I  programs,  is  re¬ 
sponsible  for  conducting  requirements  analyses,  validating  mission  needs  and  key  perform- 
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ance  parameters,  and  developing  recommended  joint  priorities  for  those  needs.  As  of  1 
January  1997,  law  under  Title  10  establishes  the  existence  of  the  JROC  and  its  functions. 

It  should  also  be  noted  that  the  Office  of  the  Secretary  of  Defense  (OSD)  Principal  Staff 
Assistants  (PSAs)  represent  the  user  community  in  the  functional  area  under  their  direc¬ 
tion  on  acquisition  and  requirements  matters  for  Automated  Information  Systems  (AISs). 
Within  the  Acquisition  Management  System,  there  is  a  clear  linkage  between  the  analysis 
of  alternatives,  system  requirements,  and  system  evaluation  measures  of  effectiveness. 

After  the  JROC  validates  the  mission  need  for  an  ACAT I  program,  the  Under  Secretary 
of  Defense  for  Acquisition  and  Technology  (USD(A&T))  shall: 

•  convene  a  Milestone  0  Defense  Acquisition  Board  (DAB)  to  review  the  Mis¬ 
sion  Need  Statement  (MNS); 

•  identify  possible  materiel  alternatives;  and 

•  authorize  concept  studies,  if  they  are  deemed  necessary. 

For  ACAT  lA  programs,  the  JROC,  or  the  cognizant  OSD  PSA,  validates  the  mission 
need  and  process  integrity  in  compliance  with  DoDD  8000.15;  and  the  Assistant  Secretary 
of  Defense  for  Command,  Control,  Communications,  and  Intelligence  (ASD(C^I))  con¬ 
venes  a  Milestone  0  Major  Automated  Information  System  Review  Council  (MAISRC). 

A  favorable  Milestone  0  decision  does  not  yet  mean  that  a  new  aequisition  program  has 
been  initiated.  Further,  when  acquisition  programs  are  initiated  in  response  to  a  military 
threat,  they  are  based  on  authoritative,  current,  and  projected  threat  information. 

3.1.4  Mission  Need  Statement  (MNS) 

DoD  Components  document  deficiencies  in  current  capabilities  and  opportunities  to  pro¬ 
vide  new  capabilities  in  the  MNS  expressed  in  broad  operational  terms.  The  MNS  shall: 

•  identify  and  describe  the  mission  deficiency  and  discuss  the  results  of  mission 
area  analysis; 

•  describe  why  non-materiel  changes  (i.e.,  doctrine,  tactics,  etc.)  are  not  ade¬ 
quate  to  correct  the  deficiency; 

•  identify  potential  materiel  alternatives;  and 

•  describe  any  key  boundary  conditions  and  operational  environments,  such  as 
information  warfare,  that  may  impact  satisfying  the  need. 

The  MNS  is  prepared  in  accordance  with  Commander,  Joint  Chiefs  of  Staff  (CJCS) 
Memorandum  of  Policy  (MOP)  77.  System  performance  objeetives  and  thresholds  are 
developed  from,  and  remain  consistent  with,  the  initial  broad  statements  of  operational 
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capability.  The  requirements  are  refined  at  suecessive  milestone  decision  points  as  a  con¬ 
sequence  of  cost-schedule-performance  tradeoffs  during  each  phase  of  the  aequisition  pro¬ 
cess. 

In  summary,  all  acquisition  programs  are  based  on  identified,  documented,  and  validated 
mission  needs,  which  result  fi'om  ongoing  assessments  of  current  and  projected  capability. 
Thus,  mission  needs  may  be  designed  to  establish  a  new  operational  capability,  to  improve 
an  existing  capability,  or  to  exploit  an  opportunity  to  reduce  costs  or  enhance  perform¬ 
ance. 

3. 1 .4. 1  Cost  Objectives.  Upon  approval  of  an  MNS,  an  approach  is  formulated  to  set  and 
refine  cost  objectives.  By  program  initiation  (usually  Milestone  I),  each  AC  AT  I  and 
ACAT  LA  PM  establishes  life-cycle  cost  objectives  for  the  program  through  consideration 
of  projected  out-year  resources,  recent  unit  eosts,  parametric  estimates,  mission  effective¬ 
ness  analysis  and  trades,  and  teehnology  trends. 

3.1.5  Evaluation  of  Requirements  Based  on  Commercial  Market  Potential 

Researching  the  potential  of  the  commercial  marketplace  to  meet  system  performance  re¬ 
quirements  is  an  essential  element  of  building  a  sound  set  of  requirements.  In  developing 
system  performanee  requirements,  DoD  Components  evaluate  how  the  desired  perform¬ 
ance  requirements  could  reasonably  be  modified  to  facilitate  the  use  of  potential  commer- 
eial  items,  components,  specifieations,  standards,  processes,  technology,  and  sources.  The 
results  of  the  evaluation  are  included  as  part  of  the  initial  Operational  Requirements 
Document. 

3.1.6  Operation  Requirements  Document  (ORD) 

At  each  milestone,  beginning  with  program  initiation  (usually  Milestone  I),  thresholds  and 
objectives  are  documented  by  the  user  or  user's  representative  in  an  ORD.  These  thresh¬ 
olds  and  objectives  are  initially  expressed  as  measures  of  effectiveness  or  performance  and 
minimum  acceptable  requirements  for  the  proposed  concept  or  system.  Thresholds  and 
objectives  in  the  ORD  are  designed  to  consider  the  results  of  the  analysis  of  alternatives 
and  the  impact  of  affordability  constraints.  Key  Performance  Parameters  (KPPs),  vali¬ 
dated  by  the  JROC,  are  included  in  the  appropriate  Acquisition  Program  Baseline  (APB). 
A  KPP  is  a  system  capability  or  characteristic  so  significant  that  failure  to  meet  the  thresh¬ 
old  can  be  cause  for  the  concept  or  system  seleetion  to  be  reevaluated  or  for  the  program 
to  be  reassessed  or  terminated.  KPPs  are  extracted  fi'om  the  ORD  and  included  in  the 
APB.  Thus,  user  or  user  representative  partieipation  in  each  acquisition  phase  is  essential. 

Thresholds  and  objeetives  are  defined  below.  The  values  for  an  objective  or  threshold  and 
definitions  for  any  specific  parameter  eontained  in  the  ORD,  Test  and  Evaluation  Master 
Plan  (TEMP),  and  APB  shall  be  consistent. 
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Threshold.  The  threshold  value  is  the  minimum  acceptable  value  that,  in  the  user's 
judgment,  is  necessary  to  satisfy  the  need.  If  threshold  values  are  not  achieved, 
program  performance  is  seriously  degraded,  the  program  may  be  too  costly,  or  the 
program  may  no  longer  be  timely.  The  spread  between  objective  and  threshold 
values  is  individually  set  for  each  program  and  is  based  on  the  characteristics  of  the 
program  (e.g.,  maturity,  risk,  etc.). 

Objective.  The  objective  value  is  the  value  desired  by  the  user  and  the  value  the 
PM  is  attempting  to  obtain.  The  objective  value  could  represent  an  operationally 
meaningful,  time-critical,  and  cost-effective  increment  above  the  threshold  for  each 
program  parameter.  Program  objectives  (parameters  and  values)  may  be  refined 
based  on  the  results  of  the  preceding  program  phase(s). 

3. 1.6.1  Performance.  Engineering,  or  Design  Changes.  The  Cost  Performance  Integrated 
Product  Team  (CPIPT)  (normally  led  by  the  PM  or  the  PM's  representative)  is  empowered 
to  recommend  to  the  PM  performance  or  engineering  and  design  changes  as  long  as  the 
threshold  values  in  the  ORD  and  APB  can  be  achieved.  If  the  changes  require  ORD/APB 
threshold  value  changes,  the  leader  of  the  CPIPT  notifies  the  PM  and  the  Overarching  In¬ 
tegrated  Product  Team  (OIPT)  leader.  The  PM  ensures  that  the  changes  are  brought  be¬ 
fore  the  ORD  and/or  APB  approval  authorities  for  decision.  The  CPIPT  has  responsibility 
for  integrating  and  evaluating  aU  cost-performance  tradeoffs  analyses  conducted. 

3. 1.6.2  Operational  Requirement  Document  (ORD)  and  Testing.  Test  and  evaluation 
strategy  shall  reference  the  ORD  as  follows; 

•  Test  planning,  at  a  minimum,  addresses  all  system  components  (hardware, 
software,  and  human  interfaces)  that  are  critical  to  the  achievement  and  demon¬ 
stration  of  contract  technical  performance  specifications  and  operational  effec¬ 
tiveness  and  suitability  requirements  fi’om  the  ORD. 

•  Quantitative  criteria  are  phrased  so  they  provide  substantive  evidence  for 
analysis  of  hardware,  software,  and  system  maturity  and  readiness  to  proceed 
through  the  acquisition  process.  Linkage  shall  exist  among  the  various  Memo¬ 
randa  of  Effectiveness  (MOEs);  Memoranda  of  Performance  (MOPs),  which 
are  used  in  the  analysis  of  alternatives  or  the  ORD;  and  test  and  evaluation.  In 
particular,  the  MOEs,  MOPs,  the  ORD  criteria,  the  analysis  of  alternatives,  the 
TEMP,  and  the  APB  shall  be  consistent. 

•  Operational  test  and  evaluation  (OT&E)  programs  shall  be  structured  to  de¬ 
termine  the  operational  effectiveness  and  suitability  of  a  system  under  realistic 
conditions  (e.g.,  combat)  and  to  determine  if  the  minimally  acceptable,  ORD- 
specified  operational  performance  requirements  have  been  satisfied. 
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3.1.7  Acquisition  Strategy  and  Life-Cycle  Support 

Each  PM  develops  and  documents  an  acquisition  strategy  that  serves  as  the  roadmap  for 
program  execution  from  program  initiation  through  postproduction  support.  In  develop¬ 
ing  an  acquisition  strategy,  a  primary  goal  is  to  minimize  the  time  and  cost  of  satisfying  an 
identified,  validated  need  that  is  consistent  with  common  sense  and  sound  business  prac¬ 
tices.  The  acquisition  strategy  evolves  through  an  iterative  process  and  becomes  increas¬ 
ingly  more  definitive  in  describing  the  relationship  of  the  essential  elements  of  a  program. 
Essential  elements  in  this  context  include,  but  are  not  limited  to,  sources,  risk  manage¬ 
ment,  cost  as  an  independent  variable,  contract  approach,  management  approach,  envi¬ 
ronmental  considerations,  and  source  of  support.  The  PM  addresses  other  major  initia¬ 
tives  that  are  critical  to  the  success  of  the  program. 

The  acquisition  strategy  includes  the  critical  events  that  govern  the  management  of  the 
prograuL  The  event-driven  acquisition  strategy  explicitly  links  program  decisions  to  dem¬ 
onstrated  accon^lishments  in  development,  testing,  initial  production,  and  life-cycle  sup¬ 
port.  The  events  set  forth  in  contracts  shall  support  the  appropriate  exit  criteria  for  the 
phase  or  preceding  development  events  that  are  established  for  the  acquisition  strategy. 

The  acquisition  strategy  is  tailored  to  meet  the  specific  needs  of  individual  programs,  in¬ 
cluding  consideration  of  incremental  (block)  development  and  fielding  strategies.  The 
benefits  and  risks  associated  with  reducing  lead  time  through  concurrency  are  specifically 
addressed  in  tailoring  the  acquisition  strategy.  In  tailoring  an  acquisition  strategy,  the  PM 
addresses  the  management  requirements  imposed  on  the  contractor(s). 

The  PM  initially  develops  the  acquisition  strategy  at  program  initiation  (usually  MOestone 
I)  and  keeps  the  strategy  current  by  updating  it  whenever  there  is  a  change  to  the  ap¬ 
proved  acquisition  strategy  or  as  the  system  approach  and  program  elements  are  better 
defined.  The  PM  develops  the  acquisition  strategy  in  coordination  with  the  Working-level 
Integrated  Product  Team.  The  Program  Executive  Officer  (PEO)  and  Component  Acqui¬ 
sition  Executive  (CAE),  as  appropriate,  concur  in  the  acquisition  strategy.  The  Milestone 
Decision  Authority  (MDA)  approves  the  acquisition  strategy  prior  to  release  of  the  formal 
solicitation.  This  approval  usually  precedes  the  milestone  review,  except  at  program  ini¬ 
tiation  when  the  strategy  usually  is  approved  as  part  of  the  initial  milestone  decision  re¬ 
view. 

Paragraphs  3.3.1  through  3.3.8  of  DoD  5000.2-R  address  acquisition-strategy  related 
topics  including: 

•  sources  of  supplies  and/or  services; 

•  risk  management; 

•  Cost  As  an  Independent  Variable; 
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contract  approach; 


•  management  approach; 

•  environmental,  safety,  and  health  considerations; 

•  sources  of  support;  and 

•  warranties. 

3. 1.7.1  Non-Traditional  Acquisitioa  The  Department  must  be  prepared  to  plan  and  exe¬ 
cute  a  diverse  variety  of  missions.  To  meet  the  user's  needs  in  a  timely  manner,  the  acqui¬ 
sition  system  must  be  able  to  rapidly  insert  advanced  technology  directly  into  the  war¬ 
fighter's  arsenal.  To  accomplish  this  goal,  the  acquisition  system  must  demonstrate  new 
and  inproved  military  capabilities  on  a  scale  adequate  to  establish  operational  utility  and 
affordable  cost.  Demonstrations  based  on  mature  technologies  may  lead  to  more  rapid 
fielding.  Where  appropriate,  managers  in  the  acquisition  community  make  use  of  non- 
traditional  acquisition  techniques,  such  as  Advanced  Concept  Technology  Demonstrations 
(ACTDs),  rapid  prototyping,  evolutionary  and  incremental  acquisition,  and  flexible  tech¬ 
nology  insertion. 

3. 1.7.2  Performance  Specification.  In  solicitations  and  contracts,  standard  management 
approaches  or  manufacturing  processes  are  not  required.  Performance  specifications  are 
used  when  purchasing  new  systems,  major  modifications,  and  commercial  and  nondevel- 
opmental  items.  Performance  specifications  include  DoD  performance  specifications, 
commercial  item  descriptions,  and  performance-based  non-government  standards.  If  it  is 
not  practicable  to  use  a  performance  specification,  a  non-government  standard  is  used. 
There  may  be  cases  when  mihtary  specifications  are  needed  to  define  an  exact  design  so¬ 
lution  because  there  is  no  acceptable  non-govemment  standard  or  because  the  use  of  a 
performance  specification  or  non-govemment  standard  is  neither  cost-effective,  practical, 
nor  does  it  meet  the  user's  needs.  As  a  last  resort  in  these  cases,  military  specifications 
and  standards  use  is  authorized  with  an  appropriate  waiver  or  exception  fi'om  the  MDA. 

3.2  LIFE-CYCLE  MANAGEMENT 


3.2.1  Event-Oriented  Management 

The  Department  uses  a  rigorous,  event-oriented  management  process  that  emphasizes: 

•  effective  acquisition  planning; 

•  improved  and  continuous  communications  with  users;  and 

•  prudent  risk  management  by  both  the  government  and  industry. 
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Event-oriented  means  that  the  management  process  is  based  on  significant  events  in  the 
acquisition  life  cycle  and  not  on  arbitrary  calendar  dates. 

3.2.2  StabiKty 

Once  DoD  initiates  an  acquisition  program  to  meet  an  operational  need,  managers  at  all 
levels  make  program  stability  a  top  priority.  To  maximize  stability,  the  Components  de¬ 
velop  realistic  long-range  investment  plans  and  affordability  assessments.  The  Depart¬ 
ment's  leadership  strives  to  ensure  stable  program  funding  throughout  the  program's  life 
cycle. 


3.2.3  Program  Objectives  and  Thresholds 

Beginning  at  the  inception  of  a  new  acquisition  program,  the  PM,  together  with  the  user, 
proposes  for  MDA  approval  objectives  and  thresholds  for  cost,  schedule,  and  performance 
that  will  result  in  systems  that  are  affordable,  timely,  operationally  effective,  operationally 
suitable,  and  survivable.  As  the  program  matures,  the  PM  refines  these  objectives  and 
thresholds  so  they  are  consistent  with  operational  requirements. 

3.2.4  Risk  Assessment  and  Management 

PMs  and  other  acquisition  managers  continually  assess  program  risks.  Risks  must  be  well 
understood,  and  risk  management  approaches  must  be  developed  before  decision  authori¬ 
ties  can  authorize  a  program  to  proceed  into  the  next  phase  of  the  acquisition  process.  To 
assess  and  manage  risk,  PMs  and  other  acquisition  managers  use  a  variety  of  techniques, 
including  technology  demonstrations,  prototyping,  and  test  and  evaluation.  Risk  manage¬ 
ment  encompasses  identification,  mitigation,  continuous  tracking,  and  control  procedures 
that  feed  back  through  the  program  assessment  process  to  decision  authorities.  To  ensure 
an  equitable  and  sensible  allocation  of  risk  between  government  and  industry,  PMs  and 
other  acquisition  managers  develop  a  contracting  approach  appropriate  to  the  type  of 
system  being  acquired. 

3.2.5  Best  Practices 

The  PM  streamlines  all  acquisitions  so  that  the  acquisitions  contain  only  those  require¬ 
ments  that  are  essential  and  cost-effective.  Contract  requirements  are  stated  in  terms  of 
performance  rather  than  design-specific  procedures.  Management  data  requirements  are 
limited  to  those  essential  for  effective  control.  Acquisition  process  requirements  are  tai¬ 
lored  to  meet  the  specific  needs  of  individual  programs.  Relief  or  exemption  is  sought  for 
those  requirements  that  are  not  essential,  cost-effective,  or  do  not  add  value.  Early  indus¬ 
try  involvement  in  the  acquisition  effort,  consistent  with  the  Federal  Advisory  Committee 
Act  (FACA27),  is  encouraged  to  take  advantage  of  industry  expertise  to  improve  the  ac¬ 
quisition  strategy.  The  PM  avoids  imposing  government-unique  requirements  that  signifi¬ 
cantly  increase  industry  eon:q)liance  costs. 
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3.2.6  Life-Cycle  Cost  Estimates 

Life-cycle  cost  estimates  are  explicitly  based  on  the  program  objectives,  operational  re¬ 
quirements,  and  contract  specifications  for  the  system.  For  ACAT  I  programs,  life-cycle 
cost  estimates  are  based  on  a  program  DoD  Work  Breakdown  Structure  (WBS);  and,  for 
ACAT  lA  programs,  life-cycle  cost  estimates  are  based  on  a  life-cycle  cost-and-benefit 
element  structure  agreed  upon  by  the  IPX.  Estimates  are  conq)rehensive  in  character. 
They  identify  all  elements  of  cost  that  would  be  entailed  by  a  decision  to  proceed  with  de¬ 
velopment,  production,  and  operation  of  the  system  regardless  of  funding  source  or  man¬ 
agement  control  For  ACAT  I  programs,  estimates  are  consistent  with  the  cost  estimates 
used  in  the  analysis  of  alternatives.  The  operation  and  support  costs  are  consistent  with 
the  manpower  estimate.  Cost  estimates  should  be  neither  optimistic  nor  pessimistic;  they 
should  be  based  on  a  careful  assessment  of  risks  and  should  reflect  a  realistic  appraisal  of 
the  level  of  cost  most  likely  to  be  realized. 

3.2.6. 1  Cost/Performance  Tradeoffs.  Upon  approval  of  a  MNS,  an  approach  is  formu¬ 
lated  to  set  and  refine  cost  objectives.  By  program  initiation  (usually  Milestone  I),  each 
ACAT  I  and  ACAT  lA  PM  shall  have  established  life-cycle  cost  objectives  for  the  pro¬ 
gram  through  consideration  of  projected  out-year  resources,  recent  unit  costs,  parametric 
estimates,  mission  effectiveness  analysis  and  trades,  and  technology  trends.  A  complete 
set  of  life-cycle  cost  objectives  includes  RDT&E,  production,  operating  and  support,  and 
disposal  costs.  At  each  subsequent  milestone  review,  cost  objectives  and  progress  to¬ 
wards  achieving  them  will  be  reassessed. 

Maximizing  the  PM’s  and  contractor’s  flexibility  to  make  cost/performance  tradeoffs 
without  unnecessary  higher-level  permission  is  essential  to  achieving  cost  objectives. 
Therefore,  the  number  of  threshold  items  in  requirements  documents  and  acquisition  pro¬ 
gram  baselines  are  strictly  limited.  The  threshold  values  represent  true  minimums;  and  re¬ 
quirements  are  stated  in  terms  of  capabilities  rather  than  technical  solutions  and  specifica¬ 
tions. 

RFPs  include  a  strict  minimum  number  of  critical  performance  criteria  that  will  allow  in¬ 
dustry  maximum  flexibility  to  meet  overall  program  objectives.  Cost  objectives  are  used 
as  a  management  tool  The  source  selection  criteria  communicated  to  industry  should  re¬ 
flect  the  importance  of  developing  a  system  that  can  achieve  stated  production  and  life- 
cycle  cost  thresholds. 

3.3  DOCUMENTATION 


T  .imited  Reporting  Requirements.  (See  Appendices  I-IV,  DoD  5(XX).2-R.)  Conqjlete  and 
up-to-date  program  information  is  an  essential  ingredient  of  the  defense  acquisition  proc¬ 
ess.  At  the  same  time,  it  is  in^ortant  to  keep  reporting  requirements  to  a  minimum.  Con¬ 
sistent  with  statutory  requirements,  PMs  and  other  participants  in  the  defense  acquisition 
process  are  required  to  present  only  the  minimum  information  necessary  for  decision 
authorities  to  understand  program  status  and  make  informed  decisions.  (Again,  refer  to 
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Appendices  I-IV,  DoD  5000.2-R,  for  the  mandatory  reports  and  formats  for  ACAT I  and 
lA  programs.)  The  exchange  of  program  information  is  facihtated  by  the  use  of  IPTs. 

3.3.1  Tailoring 

DoD  5000.2-R  presents  a  general  model  for  managing  Major  Defense  Acquisition  Pro¬ 
grams  (MDAPs)  and  Major  Automated  Information  System  (MAIS)  acquisition  programs. 
The  broad  coverage  of  the  general  model  acknowledges  that  every  acquisition  program  is 
different.  Any  singular  MDAP  or  MAIS  does  not  need  to  follow  the  entire  process  de¬ 
scribed  in  the  regulation.  However,  cognizant  of  this  model,  the  PM  and  the  MDA  must- 
structure  the  MDAP  or  MAIS  to  ensure  a  logical  progression  through  a  series  of  phases 
designed  to; 

•  reduce  risk, 

•  ensure  affordability,  and 

•  provide  adequate  information  for  decision-making  that  will  provide  the  needed 
capability  to  the  warfighter  in  the  shortest  practical  time. 

PMs  and  MDAs,  for  other  than  MDAPs  or  MAISs,  generally  adhere  to  the  process  de¬ 
scribed  in  Part  1  of  DoD  5000.2-R;  however,  they  tailor  the  process,  as  appropriate,  to 
best  match  the  conditions  of  individual  non-major  programs. 

Certain  core  issues  must  be  addressed  at  the  appropriate  milestone  for  every  acquisition 
program.  These  issues  are  described  in  detail  in  the  major  sections  of  DoD  5000.2-R  and 
include  program  structure,  design,  assessments,  and  periodie  reporting.  How  these  issues 
are  addressed  is  tailored  by  the  appropriate  MDA  to  minimize  the  time  it  takes  to  satisfy 
an  identified  need  consistent  with  common  sense,  sound  business  management  practice, 
applicable  laws  and  regulations,  and  the  time  sensitive  nature  of  the  requirement  itself. 
Tailoring  may  be  applied  to  various  aspects  of  the  acquisition  process,  including  program 
documentation,  acquisition  phases,  the  timing  and  scope  of  decision  reviews,  and  decision 
levels.  MDAs  promote  flexible,  tailored  approaches  to  oversight  and  review,  which  are- 
based  on  mutual  trust  and  a  program's  size,  risk,  and  complexity. 

3.4  LOGISTICS  REQUIREMENTS 

3.4.1  Total  System  Approach 

Acquisition  programs  are  managed  to  optimize  total  system  performance  and  minimize  the 
cost  of  ownership.  The  total  system  includes: 

•  the  prime  mission  equipment; 

•  the  people  who  operate  and  maintain  the  system; 
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•  how  the  system’s  security  procedures  and  practices  are  implemented; 

•  how  the  system  operates  in  its  intended  operational  environment; 

•  how  the  system  will  be  able  to  respond  to  any  effects  unique  to  that  environ¬ 
ment  (such  as  Nuclear,  Biological  and  Chemical  (NBC)  or  information  war¬ 
fare); 

•  how  the  system  will  be  deployed  to  this  environment; 

•  the  system's  compatibility,  interoperability,  and  integration  with  other  systems; 

•  the  operational  and  support  infrastructure  (including  command,  control,  com¬ 
munications,  computers  and  intelligence} 

•  all  related  training  and  training  devices; 

•  data  elements  required  by  the  system  in  order  for  it  to  operate;  and 

•  the  system's  potential  inpact  on  the  environment  and  the  means  for  environ¬ 
mental  conpliance. 

3.4.2  Supportability 

Supportability  factors  are  integral  elements  of  program  performance  specifications.  How¬ 
ever,  support  requirements  are  not  to  be  stated  as  distinct  logistics  elements;  instead,  they 
are  stated  as  performance  requirements  that  relate  to  a  system's  operational  effectiveness, 
operational  suitability,  and  life-cycle  cost  reduction.  Accordingly,  the  PM  ensures  that  a 
systems  engineering  process  is  used  to  translate  operational  needs  and/or  requirements 
into  a  system  solution  that  includes  the  design,  manufacturing,  test  and  evaluation,  support 
processes,  and  products.  This  will  include  transforming  operational  needs  and  require¬ 
ments  into  an  integrated  system  design  solution  through  concurrent  consideration  of  all 
life-cycle  needs  (i.e.,  development,  manufacturing,  test  and  evaluation,  verification,  de¬ 
ployment,  operations,  support,  training,  and  disposal). 

3.4.3  Acquisition  Logistics 

The  PM  conducts  acquisition  logistics  management  activities  throughout  the  system  de¬ 
velopment  to  ensure  the  design  and  acquisition  of  cost-effective,  supportable  systems  and 
to  ensure  that  these  systems  are  provided  to  the  user  with  the  necessary  support  infra¬ 
structure  for  achieving  the  user's  peacetime  and  wartime  readiness  requirements. 

3.4.3. 1  Supportability  Analyses.  Supportability  analyses  are  conducted  as  an  integral  part 
of  the  systems  engineering  process,  beginning  at  program  initiation  and  continuing 
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throughout  system  development.  Supportability  analyses  form  the  basis  for  related  design 
requirements  included  in  the  system  specification  and  for  subsequent  decisions  concerning 
how  to  support  the  system  in  the  most  cost-effective  manner  over  its  entire  Ufe  cycle. 
Programs  allow  contractors  the  maximum  flexibility  in  proposing  the  most  appropriate 
supportability  analyses. 

3.4.3.2  Support  Concepts.  Acquisition  programs  establish  logistics  support  concepts 
(e.g.,  two  levels,  three  levels)  early  in  the  program  and  refine  them  throughout  the  devel¬ 
opment  process.  Life-cycle  costs  play  a  key  role  in  the  overall  selection  process.  Support 
concepts  for  new  and  future  systems  provide  for  cost  effective,  total  life-cycle  logistics 
support. 

3.4. 3.3  Support  Data.  Data  requirements  shall  be  consistent  with  the  planned  support 
concept  and  represent  the  minimum  essential  to  effectively  support  the  fielded  system 
Government  requirements  for  contractor-developed  support  data  are  coordinated  with  the 
data  requirements  of  other  program  functional  specialties  to  minimize  data  redundancies 
and  inconsistencies. 

3.4.3.4  Support  Resources.  Support  resources,  such  as  operator  and  maintenance  manu¬ 
als,  tools,  support  equipment,  training  devices,  etc.,  for  major  system  components,  are  not 
procured  before  the  system/component  hardware  and  software  design  stabilizes.  The  PM 
considers  the  use  of  embedded  training  and  maintenance  techniques  to  enhance  user  capa¬ 
bility  and  reduce  life-cycle  costs.  Where  they  are  available,  cost-effective,  and  can  readily 
meet  the  user's  requirements,  commercial  support  resources  are  used. 

DoD  Automatic  Test  System  (ATS)  families  or  COTS  components  that  meet  defined  ATS 
capabilities  are  used  to  meet  all  acquisition  needs  for  automatic  test  equipment  hardware 
and  software.  ATS  capabilities  are  defined  through  critical  hardware  and  software  ele¬ 
ments.  The  introduction  of  unique  types  of  ATS  into  the  DoD  field,  depot,  and  manufac¬ 
turing  operations  are  minimized. 

3.5  CORE  MAINTENANCE 


It  is  DoD  policy  to  retain  limited  organic  core  depot-maintenance  capability  to  meet  es¬ 
sential  wartime  surge  demands,  promote  competition,  and  sustain  institutional  expertise. 
Support  concepts,  for  new  and  modified  systems,  maximize  the  use  of  contractor- 
provided,  long-term,  total  life-cycle  logistics  support  that  combines  depot-level  mainte¬ 
nance  along  with  wholesale  and  selected  retail  materiel  management  functions.  Life-cycle 
costs  and  use  of  existing  capabilities,  particularly  while  the  system  is  in  production,  plays  a 
key  role  in  the  overall  selection  process.  Other  than  stated  above  and  with  an  appropriate 
waiver,  DoD  organizations  may  be  used  as  substitutes  for  contractor-provided  logistics 
support,  such  as  when  contractors  are  unwilling  to  perform  support  or  where  there  is  a 
clear,  well-documented  cost  advantage.  The  PM  provides  for  long-term  access  to  data 
required  for  competitive  sourcing  of  systems  support.  The  waiver  to  use  DoD  organiza¬ 
tions  must  be  approved  by  the  MDA.  It  should  be  noted  that  recent  studies  (1996/97)  by 
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the  Defense  Science  Board  have  concluded  that,  in  order  to  free-up  funds  for  system  mod¬ 
ernization,  the  organic  core  maintenance  capability  retained  by  the  DoD  should  be  even 
less  than  that  implied  above. 

3.6  DEVELOP  A  SEAMLESS  LOGISTICS  SYSTEM 

3.6.1  Fielding  Standard,  Modernized  Logistics  Business  Systems  and  Improving 
Communications  of  Logistics  Systems 

Clearly,  seamless,  standard,  modem  logistics  business  systems  can  bring  many  benefits  to 
the  DoD  in  the  areas  of  financial  accounting,  management,  and  industrial/production  op¬ 
erations.  Thus,  developing  such  systems  is  clearly  a  DoD  goal  in  the  context  of  acquisi¬ 
tion  reform.  However,  the  launching  of  a  new  business  system  is  a  difficult  technical  and 
financial  task.  The  costs  of  alternative  methods  of  developing  business  systems  and  their 
operation  and  maintenance  can,  in  some  cases,  offer  little  or  no  net  economic  gain  or  a 
competitive  return  on  investment.  Even  the  most  optimum  alternative  for  bringing  a  mod¬ 
em  system  into  full  operation  may  require  an  extended  period  before  benefits  exceed 
costs.  In  the  meantime,  the  new  system  is  likely  to  become  outdated.  Further,  alternative 
solutions,  which  require  extended  payback  periods,  tend  to  rely  on  too  many  assumptions 
because  the  needed  facts  to  support  management  decisions  are  not  available.  Finally,  the 
affordability  factor  or  financial  priority  for  such  systems,  in  the  context  of  other  DoD 
funding  needs,  may  not  be  sufficient  to  get  a  new  business  system  started,  much  less  to  get 
it  started  on  an  optimum  course.  If  the  system  has  a  direct  link  to  operational  readiness,  as 
many  do,  the  system’s  affordability  may  be  enhanced. 

This  being  the  environment  impacting  the  initiation  and  maintenanee  of  much  needed  new 
business  systems,  a  summary  of  the  management  challenges  facing  a  recent  effort  to  mod¬ 
ernize  a  logistics/financial  system  with  clear  readiness  impact  is  briefly  presented  below. 
The  hope  is  that  this  summary  wiU  alert  the  reader  to  the  depth  and  breadth  of  representa¬ 
tive  issues  encountered  in  the  initiation  or  modernization  of  a  DoD  logistics  business  sys- 
tenL 

The  previous  Defense  Working  Capital  Fund  (DWCF)  (known  earlier  as  the  Defense 
Business  Operating  Fund)  Corporate  Board  desired  to  increase  the  capability  of  the  ac¬ 
counting  systems  that  were  used  in  the  Depot  Maintenance  Business  Area  (DMBA)  of  the 
DWCF.  Also,  they  desired  to  decrease  the  number  of  accounting  systems  in  the  DMBA, 
to  increase  standardization,  and  deerease  costs. 

The  DWCF  Corporate  Board  required  an  analytical  basis  to  aid  them  in  deciding  whether 
it  was  preferable  to: 

•  reduce  the  number  of  accounting  systems  by  moving  to  a  separate,  single  sys¬ 
tem  for  each  of  the  three  Mihtary  Departments  (Option  One);  or 

•  move  to  a  single  system  for  all  DoD  DMBA  activities  (Option  Two). 
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These  two  options  resulted  from  an  apparent  conflict.  The  logistics  community  was  pur¬ 
suing  a  single  depot-maintenance  information  system  that  incorporated  both  production 
and  accounting  capabilities  while  the  Defense  Finance  and  Accounting  Service  (DFAS) 
was  recommending  three  depot-maintenance  accounting  systems  —  one  for  each  Military 
Department  as  opposed  to  the  several  each  Service  now  has.  Therefore,  the  Under  Sec¬ 
retary  of  Defense  (Comptroller)  or  USD(C)  was  concerned  that  significant  investments 
could  be  made  in  the  accounting  systems  for  each  Military  Department;  and,  shortly  there¬ 
after,  a  single  system  associated  with  the  single  production  system  would  replace  them. 
The  USD(C)  then  directed  that  an  economic  analysis  be  performed  so  that  the  DWCF 
Corporate  Board  would  have  the  cost  information  needed  to  make  an  informed  decision 
on  the  preferable  option. 

The  DFAS  had  already  identified  the  candidate  systems  for  Option  One  as  the: 

•  Standard  Industrial  Fund  Accounting  System  (SIFS)  for  the  Army; 

•  Naval  Air  Systems  Command  Industrial  Fund  Management  System  (NIFMS) 
for  the  Navy;  and  the 

•  financial  modules  of  the  Depot  Maintenance  Management  Information  System 
(DMMIS)  financial  system  for  the  Ak  Force. 

Candidates  for  the  single  DoD  system  in  Option  Two  were  limited  to  those  same  systems. 

The  economic  analysis  concluded  that  Option  One  (a  separate  accounting  system  for  each 
Military  Department  from  those  systems  currently  available)  was  preferable  to  Option 
Two  (a  single,  new  accounting  system  for  all  DoD  depots).  For  the  reasons  stated  below, 
the  single  set  of  production  systems  has  not  come  about  and  is  not  currently  planned.  In¬ 
stead,  each  Service  will  continue  with  a  unique  set  of  updated  production  systems  that 
feed  into  the  financial  systems.  Therefore,  Option  One  was  chosen  because  multiple  in¬ 
terfaces  would  have  to  be  developed  for  any  accounting  system  chosen  as  the  single,  stan¬ 
dard  system  (Option  Two).  That  interface  problem,  combined  with  the  unique  business 
practices  followed  by  each  Service  and  the  additional  deployments  Option  Two  would  re¬ 
quire,  increased  the  investment  costs  of  Option  Two  relative  to  Option  One.  Increased 
investment  costs  in  the  face  of  decreased  operating  and  support-cost  savings  made  a  sin¬ 
gle,  shared  accounting  system  a  poor  choice  at  the  time.  If  the  depot  production  systems 
and  business  practices  evolve  toward  a  single  system  in  the  future,  then  the  option  of  a 
single  accounting  system  becomes  more  attractive. 

While  Option  One  was  preferable,  it  was  not  uncostly.  Estimating  the  cost  of  this  option 
was  essential  to  making  decisions  on  the  extent  of  system  consolidation  and  timing.  The 
economic  analysis  provided  estimates  of  the  cost  of  upgrading  the  three  systems  to  meet 
the  functional  requirements  specified  by  DFAS  and  of  deploying  them  to  all  maintenance 
depots  in  their  respective  Military  Departments. 
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The  analysis  of  SIFS  showed  that,  for  a  one-time  investment  cost  of  $4.9  million,  SIFS 
could  be  upgraded  and  deployed  to  the  three  Army  arsenals.  Operating  and  support  costs 
would  remain  unchanged.  SIFS  would  improve  the  functionality  of  the  existing  arsenal 
systems  and  standardize  DWCF  accounting  within  the  Army. 

The  analysis  of  NIFMS  was  more  complex.  Because  NIFMS  was  being  deployed  first  to 
the  Navy  R&D  community,  some  costs  were  paid  during  that  deployment  and  were  not 
paid  again  by  the  DBMA  community.  The  total  one-time  investment  cost  of  upgrading 
NIFMS  and  deploying  it  to  all  Marine  Corps  and  Navy  maintenance  depots  ranged  fi-om 
$23.2  million  (at  the  50  percent  confidence  level)  to  $27.8  million  (at  the  90  percent  con¬ 
fidence  level).  Because  some  of  this  cost  was  shared  with  the  R&D  community,  the  in¬ 
cremental  investment  cost  was  $17.4  million  to  $19.9  million.  As  a  result  of  deploying 
NIFMS,  the  operating  and  support  costs  increased  for  Marine  Corps  logistics  bases,  naval 
ordnance  centers,  and  naval  shipyards. 

The  investment  costs  of  deploying  NIFMS  to  naval  shipyards  were  substantial  ($1 1.7  mil¬ 
lion  to  $13.9  million).  This  raised  the  question  of  whether  it  was  less  costly  to  upgrade 
the  existing  financial  management  system  at  the  shipyards  rather  than  replace  it  with 
NIFMS.  Another  option  was  for  NIFMS  to  use  an  open  systems  environment  configura¬ 
tion;  this  configuration  would  result  in  significantly  lower  subsequent  investment  and  op- 
erating-and-support  costs. 

The  analysis  of  DMMIS  raised  some  very  serious  questions.  The  largest  cost  for  DMMIS 
may  have  been  to  make  it  work  as  advertised  rather  than  to  upgrade  its  functionality. 
DMMIS  does  not  now  accurately  report  costs  of  depot  maintenance.  Further,  the 
DMMIS  financial  subsystems,  alone,  did  not  provide  coverage  for  all  of  an  Air  Logistics 
Center’s  (ALC’s)  workload.  The  costs  of  these  and  other  needed  repairs  were  uncertain. 
Deployment  costs  to  date  at  the  Wamer-Robins  ALC  had  been  substantial,  yet  the  system 
is  not  yet  running  properly.  Nonetheless,  the  economic  analysis  estimated  $5  million  to 
$15  million  for  upgrading  DMMIS  to  DFAS  standards;  about  $3  million  for  deploying 
DMMIS  to  Wamer-Robins  ALC  and  Oklahoma  City  ALC;  and  $2  to  $3  million  for  devel¬ 
oping  and  deploying  supplemental  systems  to  cover  aU  ALC  workload.  This  did  not  in¬ 
clude  the  cost  of  fixing  the  DMMIS  financial  subsystems  so  that  they  worked  properly  or 
the  cost  of  fixing  and  validating  retained  systems. 

In  summary,  the  costs  of  business  systems  can  range  from  those  that  are  easily  estimated 
to  those  that  have  an  estimate  with  a  low  level  of  confidence  and  a  poor  cost/benefit  ratio 
or  return  on  investment.  Affordability  or  relative  funding  priority  will  always  be  an  issue. 
These  problems  are  often  tied  to  technical  uncertainty  and  poorly  understood  risks.  How¬ 
ever,  as  with  all  engineering  matters,  the  application  of  solid  systems  engineering  skills, 
appropriate  testing,  and  other  tailored  DoD  acquisition  policies  and  best  commercial  prac¬ 
tices  can  create  an  environment  in  which  well-justified  programs  can  succeed. 
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4 

INTEGRATED  PRODUCT 
AND  PROCESS 
DEVELOPMENT  (IPPD) 


“IPPD  is  a  management  technique  that  simultaneously  integrates  all  es¬ 
sential  acquisition  activities  through  the  use  of  multi-disciplinary  teams  to 
optimize  the  design,  manufacturing,  and  supportability  process.  ...  IPTs 
are  the  key  to  making  IPPD  work.  ” 

Secretary  of  Defense  Memo  of  10  May  1995 


4.1  BACKGROUND 


In  order  to  lay  the  groundwork  for  Integrated  Product  and  Process  Development  and  In¬ 
tegrated  Product  Teams  (IPTs),  a  brief  discussion  of  related  events  is  presented  that  tends 
to  justify  the  decision  to  employ  IPPD  and  show  their  relevance  to  the  current  business 
environment  and  the  DoD  acquisition  process. 

4.2  GT.ORAT.  CHANGES 

To  a  great  extent,  this  topic  deals  with  human  skills,  organizational  changes,  and  team 
leadership.  These  are  areas  that  have  been  significantly  impacted  by  recent  changes  in  the 
global  environment  brought  about  by  shifts  in  technology,  markets,  labor,  production,  or¬ 
ganizational  focus,  management  enphasis,  and  organizational  structure.  Examples  of  each 
shift  includes  automated  computational-based  technologies,  rapidly  changing  markets, 
management’s  focus  on  customers,  a  shift  from  an  emphasis  on  employee  control  to  an 
emphasis  on  flexibility,  and  organizations  shifting  to  horizontal  team-oriented  structures. 
Today,  because  of  these  global  business  changes,  organizations  focus  outward  —  external, 
individual  performance  is  based  on  continual  improvement;  the  relationship  of  workers  is 
now  team-oriented;  and  a  leadership  style,  based  on  worker  empowerment,  is  used.  Simi¬ 
lar  changes  are  also  occurring  in  the  DoD. 

4.3  CHANGES  IN  DOD 

Since  the  late  80s  and,  particularly,  in  the  90s,  DoD  has  undergone  deep  budget  and  per¬ 
sonnel  reductions  that  have  resulted  in  major  changes  in  acquisition  management  —  fewer 
dollars,  fewer  people,  and  fewer  programs.  Thus,  DoD  cannot  begin  to  afford  to  conduct 
the  acquisition  business  using  the  processes  applicable  to  the  period  prior  to  1992.  For 
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these  reasons,  combined  with  the  changes  in  the  global  business  environment,  DoD  acqui¬ 
sition  management  needs  to  be  even  more  effective  in  its  leadership  while  achieving  new 
levels  of  flexibility  and  adaptability. 

4.4  LEADERSHIP  AND  MANAGEMENT  STYT.R 

As  these  global  and  DoD  changes  have  occurred,  a  style  known  as  team  leadership  has 
been  effective.  The  team  leader  tends  to  place  emphasis  on  building  trust  and  inspiring 
teamwork,  facilitating  and  supporting  team  decisions,  expanding  team  capabilities,  creat¬ 
ing  a  team  identity,  making  the  most  of  team  differences,  and  foreseeing  and  influencing 
change.  This  leader,  in  the  form  of  an  acquisition  manager,  operates  in  a  framework  that 
is  affected  by  the  global  and  DoD-wide  changes  created  by  industry  and  government 
downsizing.  Leaders  have  to  be  proactive  in  setting  the  direction  for  their  programs, 
aligning  their  people  to  the  purpose  of  the  program,  and  motivating  those  within  the  pro¬ 
gram  office  and  the  functional  personnel  who  are  part  of  the  program  management  team. 
See  Table  4A  (at  the  end  of  this  Chapter)  for  a  list  of  characteristics  of  effective  teams. 

4.5  PARADIGMS 


Paradigms  are  the  models  we  use  to  screen  incoming  data.  They  influence  our  perceptions 
and  judgments.  We  see  best  what  matches  our  paradigms.  Problems  arise  when  the  in¬ 
coming  data  do  not  match  the  expectations  that  are  created  by  our  paradigms.  As  a  result, 
we  become  blind  to  new  opportunities  because  they  do  not  fit  our  paradigms. 

What  are  the  recent  paradigm  changes  that  will  have  an  impact  upon  leaders  and  managers 
in  the  acquisition  management  business?  Experts  have  identified  seven  paradigm  changes 
that  are  necessary  for  success  in  the  1990s.  Briefly  these  changes  are: 

•  quality  redefined, 

•  continuous  inprovement, 

•  people  make  the  difference, 

•  process  improvement  versus  results, 

•  system  thinking, 

•  horizontal  structure,  and 

•  teams  as  a  system 
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4.6  ORGANIZATIONS 


Organizations  that  have  not  adapted  to  the  paradigms  noted  previously  have  been  classi¬ 
fied  by  certain  authors  as  “stuck”  organizations.  These  organizations  are  internally  driven; 
they  make  their  decisions  based  on  professional  or  departmental  interest  and  not  on  up¬ 
dated  information  about  customers’  changing  needs.  They  are  also  functionally  focused 
and  organized  as  a  collection  of  separate  functional  departments  or  “stove  pipes,”  which 
waste  time  and  energy  conq)eting  with  each  other  for  resources  and  rewards.  The  overall 
intact  of  this  functional  focus  is  reduction  in  quality  and  increase  in  cycle  times  and  costs. 
Finally,  stuck  organizations  are  management-centered.  The  managers  see  themselves  as 
the  key  players  in  the  organization  and  assume  a  need  to  control  almost  everything.  At 
times,  t^  results  in  workers  being  denied  the  information,  skills,  experience,  and  authority 
they  need  to  make  inprovements  to  the  processes  they  are  responsible  for. 

In  contrast,  organizations  that  have  adapted  to  the  above-noted  paradigm  of  the  1990s 
have  been  referred  to  as  “moving”  organizations.  They  are  customer-driven,  so  they  can 
quickly  and  continuously  understand,  meet,  and  exceed  their  customers’  changing  expec¬ 
tations.  They  are  also  process-focused.  They  bridge  the  gaps  between  functional  depart¬ 
ments  by  understanding,  tracking,  improving,  and  speeding  up  the  work  processes  by 
moving  horizontally  across  the  organization.  Finally,  moving  organizations  recognize  the 
world  is  moving  too  quickly  for  managers  to  know  enough,  fast  enough,  about  enough 
things,  to  consistently  make  the  right  decisions,  to  masterfully  control  situations,  and  to 
keep  the  organization  fi'om  being  swamped.  Therefore,  moving  organizations  become 
employee-involved.  They  undertake  a  systematic  effort  to  build  and  benefit  from  the 
knowledge,  skills,  and  commitment  of  their  nonmanagers.  Because  of  their  closeness  to 
work  processes  and  the  customer  and  because  of  their  sheer  numbers,  nonmanagers  can 
know  enough,  fast  enough,  to  in^rove  work  processes. 

The  above  organizational  definitions  and  paradigm  changes  have  brought  about  a  need  for 
leaders  and  managers  to  change  their  roles  to  some  extent.  In  a  traditional  environment, 
managers  determined  and  planned  the  work  and  “best  methods,”  narrowly  defined  jobs, 
viewed  cross-training  as  inefficient,  regarded  information  as  “management  property,”  fo¬ 
cused  nonmanagerial  training  on  technical  skills,  and  discouraged  risk  taking.  However,  in 
the  team  environment,  managers  and  team  members  jointly  determine  and  plan  the  work, 
jobs  require  broad  skills  and  knowledge,  cross  training  is  the  norm,  and  most  information 
is  fi’eely  shared  at  all  levels.  Figure  4-1  offers  a  more  conplete  comparison  of  the  two  or¬ 
ganizational  environments. 

4.7  TRADITIONAL  AND  TEAM  ENVIRONMENTS  AND  LEADERSHIP 
SKILLS 


We  should  now  begin  to  think  of  IPPD  and  EPTs  in  the  context  of  the  prior  discussions,  while 
considering  the  characteristics  of  three  types  of  leadership  skills.  Addressed  below,  are  the 
leadership  skills  that  define  a  supervisory  leader,  a  participative  leader,  and  a  team  leader. 
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Traditional  Environment 

Team  Environment 

•  Managers  determine  and  plan  the  work. 

•  Managers  and  team  members  jointly 

determine  and  plan  the  work. 

•  Jobs  are  narrowly  defined. 

•  Jobs  require  broad  skills  and 

knowledge. 

•  Cross-training  viewed  as  inefficient. 

•  Cross-training  is  the  norm. 

•  Most  information  is  “management 

•  Most  information  is  freely  shared  at 

property.” 

all  levels. 

•  Training  for  nonmanagers  focuses 

•  Continuous  learning  requires 

on  technical  skills. 

interpersonal,  administrative,  and 

technical  training  for  all. 

•  Risk  taking  is  discouraged  and 

•  Measured  risk-taking  is  encouraged 

punished. 

and  supported. 

•  People  work  alone. 

•  People  work  together. 

•  Rewards  are  based  on  individual 

•  Rewards  are  based  on  individual 

performance. 

performance  and  contributions  to 

team  performance. 

•  Managers  determine  “best  methods.” 

•  Everyone  works  to  continuously 

improve  methods  and  processes. 

Figure  4.1;  Comparison  of  Organizational  Environments 

The  supervisory  leader  is  skilled  in  directing  people,  explaining  decisions,  training  individuals, 
managing  one-on-one,  containing  conflict,  and  reacting  to  change.  This  type  of  leader 
emphasizes  the  top-down  authority  of  a  position  and  is  effective  in  a  traditional  environ¬ 
ment;  but  this  person  is  less  successful  in  a  team  environment.  The  participative  leader  has 
skdls  to  work  with  employees  rather  than  dictate  to  them.  This  type  of  leader  involves 
people,  gets  their  input  for  decisions,  develops  individual  performance,  coordinates  group 
effort,  resolves  conflict,  and  implements  change.  The  team  leader  moves  away  from  the 
“control”  world  and  focuses  on  building  shared  commitment,  responsibility,  and  leader¬ 
ship.  This  type  of  leader  builds  trust  and  inspires  teamwork,  facilitates  and  supports  team 
decisions,  expands  team  capabilities,  creates  a  team  identity,  makes  the  most  of  team  dif¬ 
ferences,  and  foresees  and  influences  change. 
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4.8  INTEGRATED  PRODUCT  AND  PROCESS  DEVELOPMENT  (IPPD)  AND 
INTEGRATED  PRODUCT  TEAMS  gPTs) 


DoDD  5000.1,  of  15  March  1996,  states  in  part,  “PMs  and  other  acquisition  managers 
shall  apply  the  concept  of  IPPD  throughout  the  acquisition  process  to  the  maximum  extent 
practicable.  ...  At  the  core  of  IPPD  implementation  are  Integrated  Product  Teams 
(IPTs).” 

IPTs,  sometimes  called  cross-functional  teams,  have  thus  become  increasingly  com¬ 
mon  in  program  management  within  DoD.  IPTs  are  the  heart  of  IPPD,  a  philosophy 
that  produces  an  effective  and  efficient  product  that  satisfies  customers’  needs.  It 
systematically  employs  a  teaming  of  functional  disciplines  to  integrate  and  concur¬ 
rently  apply  all  necessary  processes.  In  DoD  5000.2-R,  the  IPPD  definition  states, 
“One  of  the  key  IPPD  tenants  is  multi-disciplinary  teamwork  through  Integrated 
Product  Teams  (IPT).” 

IPTs  apply  and  buUd  on  subjects  discussed  before  in  terms  of  global  change,  team  leader¬ 
ship,  needed  paradigm  changes  for  the  1990s,  moving  organizations,  and  a  team  environ¬ 
ment  with  a  team-type  leader.  In  addition  they: 

•  reduce  cycle  times  by  replacing  serial  development  with  parallel  development; 

•  facilitate  reaching  solutions  to  complex  problems  that  transcend  different  disci¬ 
plines  and  functions; 

•  focus  the  organization’s  resources  on  satisfying  the  customer’s  needs; 

•  provide  a  creative  mix  of  people  with  different  backgrounds,  orientations, 
cultural  values,  and  styles,  which  increases  the  probability  of  new  ideas  and 
innovations; 

•  provide  opportunities  for  members  to  develop  new  technical  and  professional 
skills,  learn  about  other  disciplines,  and  learn  how  to  work  with  people  who  have 
different  styles  and  backgrounds;  and 

•  provide  a  place  where  people  can  go  for  information  and  for  decisions  about  a 
project,  program,  or  customer. 

In  spite  of  their  proliferation  and  advantages,  some  IPTs  fail  because  senior  managers  do 
not  give  the  team  leaders  training  in  critical  interpersonal,  group  process,  and  team  leader¬ 
ship  skills.  Sometimes  team  members  are  not  empowered  by  their  supervisors  to  fulfill 
their  role  as  an  IPT  member.  Some  offices  attempt  to  exert  oversight  authority  in  an  older 
style  of  management  when  they  really  do  not  have  oversight  authority.  Some  offices  with 
oversight  authority  over-reach  their  authority  in  violation  of  the  spirit  of  IPPD  and  IPTs. 
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Many  technically  trained  professionals  lack  the  experience  of  working  effectively  in 
groups.  In  fact,  many  scientists  and  engineers  chose  their  profession  because  it  involved 
working  independently  with  minimal  supervision  and  interpersonal  contact.  However,  as 
the  number  of  IPTs  increase,  these  professionals  are  being  selected  as  IPX  leaders.  At  a 
minimum,  IPX  leaders  should  be  proficient  in  the  IPX  leadership  elements  including: 

•  group  process  skills, 

•  leadership  empowerment, 

•  flexibility, 

•  conflict  resolution, 

•  stakeholder  relationships, 

•  resource  allocation,  and 

•  communications  coordination. 

4.9  IPPD/IPT  AND  LOGTSTTCS 

As  noted  above,  IPPD  involves  multidisciplinary  teamwork  through  IPXs.  Xhus,  the  first 
job  in  a  logistics  IPX,  is  to  define  its  membership  and  who  is  responsible  for  what!  An  ac¬ 
quisition  logistics  IPX  employing  “best  practices”  could  organize  as  follows: 

•  Purpose:  Optimize  system  support. 

•  Activities:  Prepare/coordinate  logistics  plans  and  activities. 

•  Typical  team  members  include: 

—  government  and  contractor  logistics  managers; 

—  design  engineers  and  testers; 

—  logistics  element  representatives; 

—  users  and  training  commands;  and 

—  others  as  necessary  (cost,  contacts,  etc.). 

Xable  4 A  (at  the  end  of  this  Chapter)  lists  many  of  the  attributes  of  an  effective  teanx 
Having  established  a  purpose  and  defined  its  membership,  the  logistics  IPX  will  logically 
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need  to  address  in  greater  detail  its  activities  and  related  actions.  These  functions  should 
include: 

•  working  with  the  users  to  define  their  logistics  constraints  and  requirement  in 
the  Mission  Need  Statement  and  Operational  Requirements  Documents; 

•  identifying/defining,  through  supportability  analyses  and  other  tools,  the  lo¬ 
gistics  support  requirements  for  each  proposed  design  alternative  (normally 
done  in  a  logistics  support  plan  or  equivalent); 

•  advocating  selection  of  the  most  cost-effective,  supportable  system  from 
among  design  alternatives; 

•  influencing  detailed  design  decisions  toward  a  more  cost-effective,  supportable 
design; 

•  refining  logistics  support  plans  at  the  same  pace  and  depth  at  which  the  concur¬ 
rent  engineering  team  is  working; 

•  fostering  test  and  evaluation  of  the  system  and  logistics  support  to  the  maxi¬ 
mum  practicable  extent; 

•  acquiring  all  necessary  items  of  support  (previously  identified  in  the  logistics 
support  plan)  concurrently  with  system  acquisition; 

•  providing  the  system  and  all  its  requisite  support  to  users  in  the  right  places,  at 
the  right  time,  and  in  the  right  quantities  throughout  its  service  life;  and 

•  improving  logistics  support  through  the  inevitable  modification,  change,  and 
improvement  process. 

4.10  SUMMARY 

In  conclusion,  IPPD  and  IPTs  have  origins  in  the  new  paradigms  of  the  1990s  that  have 
presented  the  case  for  organizations  to  change  fi'om  “stuck”  organizations  to  “moving” 
organizations.  At  the  same  time,  the  organizational  environments  have  changed  from  a 
traditional  to  a  team  environment.  This  has  made  it  necessary  for  leaders  to  change  their 
style  fi’om  supervisory;  to  participative;  and,  then,  to  team  leader.  IPTs  can  take  advan¬ 
tage  of  these  changes  while  employing  the  noted  and  implied  team  and  leadership  skills  to 
enhance  their  performance,  in  general,  and  logistics  IPTs,  in  particular. 
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TABLE  4A 

CHARACTERISTICS  OF  AN  EFFECTIVE  TEAM 


1 .  Has  a  clear  understanding  of  its  purpose  and  goals. 

2.  Is  flexible  in  selecting  its  procedures  as  it  works  toward  its  goals. 

3.  Has  achieved  a  high  degree  of  communication  and  understanding  among  its  mem¬ 
bers.  Communication  of  personal  feeling,  attitudes,  as  well  as  ideas  occurs  in  a  direct 
and  open  fashion  because  they  are  considered  inportant  to  the  work  of  the  group. 

4.  Is  able  to  initiate  and  carry  on  effective  decision  making,  carefully  considering  mi¬ 
nority  viewpoints  and  securing  the  commitment  of  aU  members  to  important  deci¬ 
sions. 

5.  Achieves  an  appropriate  balance  between  group  productivity  and  the  satisfaction  of 
individual  needs. 

6.  Provides  for  sharing  of  leadership  responsibilities  by  group  members.  By  sharing 
leadership  responsibilities,  aU  members  are  concerned  about  contributing  ideas, 
elaborating  and  clarifying  the  ideas  of  others,  giving  opinions,  testing  the  feasibility  of 
potential  decisions,  helping  the  group  work  on  its  tasks,  and  maintaining  itself  as  an 
effective  working  unit. 

7.  Has  a  high  degree  of  cohesiveness  (attractiveness  for  the  members)  but  not  to  the 
point  of  stifling  individual  freedom  and  submerging  individual  differences. 

8.  Makes  intelligent  use  of  the  different  abilities  of  its  members. 

9.  Is  not  dominated  by  its  leader  or  any  of  its  members. 

10.  Can  be  objective  about  reviewing  its  own  processes  and  can  face  its  problems  and 
adjust  to  needed  modifications  in  its  operations. 

1 1 .  Maintains  a  balance  between  emotional  and  rational  behavior  and  channels  emotions 
into  productive  group  effort. 


Source:  The  Leader  Looks  at  Group  Effectiveness,  Gordon  L  Lippitt  and  Edith  W. 
Seashore.  Leadership  Resources,  Inc.,  Fall  Church,  VA,  1976 
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PARTH 


THE  LOGISTICS  PROGRAM 


5 

GETTING  STARTED 

or 

Identifying  the  Need,  the  Deficiencies,  and  the  Constraints 

5.1  OVERVIEW  OF  THE  INITIATION  PROCESS 

The  acquisition  process  is  structured  in  logical  phases  separated  by  major  decision  points 
called  milestones.  The  process  begins  with  the  identification  of  broadly  stated  mission 
needs  that  cannot  be  satisfied  by  nonmateriel  solutions.  Acquisition  program  stakeholders 
consider  the  full  range  of  alternatives  prior  to  deciding  to  initiate  a  new  Defense  Acquisi¬ 
tion  Program  or  Automated  Information  System  acquisition  program.  Threat  projections, 
system  performance,  unit  production  cost  estimates,  life-cycle  costs,  interoperability,  cost- 
performance-schedule  tradeoffs,  acquisition  strategy,  affordability  constraints,  and  risk 
management  are  major  considerations  at  each  milestone  decision  point,  including  the  deci¬ 
sion  to  start  a  new  program. 

At  program  initiation  and  after  consideration  of  the  views  of  the  Working-Level  Integrated 
Product  Team  (IPT)  and  Overarching  IPT  members  (the  latter  for  AC  AT  I  and  lA  pro¬ 
grams  only),  the  PM  proposes  and  the  Milestone  Decision  Authority  considers  for  ap¬ 
proval  the  appropriate  milestones,  the  level  of  decision  for  each  milestone,  and  the  docu¬ 
mentation  needed  for  each  milestone.  For  this  proposal,  the  size,  complexity,  and  risk  of 
the  program  are  considered.  The  determinations  made  at  program  initiation  are  reexam¬ 
ined  at  each  milestone  in  light  of  then-current  program  conditions. 

5.1.1  Determining  Mission  Needs  and  Identifying  Deficiencies 

All  acquisition  programs  are  based  on  identified,  documented,  and  validated  mission 
needs.  Mission  needs  result  from  ongoing  assessments  of  current  and  projected  capability. 
Mission  needs  may  be  designed  to  establish  a  new  operational  capability,  improve  an  ex¬ 
isting  capability,  or  exploit  an  opportunity  to  reduce  costs  or  enhance  performance.  First, 
DoD  Components  try  to  satisfy  mission  needs  through  nonmateriel  solutions,  such  as 
changes  in  doctrine  or  tactics.  If  a  nonmateriel  solution  is  deemed  not  feasible,  the  Com¬ 
ponent  documents  its  considerations  and  determines  whether  the  potential  materiel  solu¬ 
tion  could  result  in  an  ACAT I  or  ACAT  LA  (see  Hierarchy  of  Materiel  alternatives  in 
DoDD  5000.1).  If  the  potential  materiel  solution  could  result  in  a  new  ACAT  I,  the  Joint 
Requirements  Oversight  Council  (JROC)  reviews  the  documented  mission  need,  deter¬ 
mines  its  validity,  and  establishes  joint  potential.  If  the  potential  solution  could  result  in  a 
new  ACAT  LA,  the  appropriate  OSD  Principal  Staff  Assistant  (PSA)  or  the  JROC  reviews 
the  documented  need,  determines  its  validity,  establishes  joint  potential,  and  confirms  that 
the  requirements  defined  in  DoDD  8000.1  have  been  met. 


5-1 


5.2  MISSION  NEEDS  STATEMENT  AND  LOGISTICS  CONSTRAINTS 


DoD  Components  document  deficiencies  in  current  capabilities  and  opportunities  to  pro¬ 
vide  new  capabilities  in  a  Mission  Need  Statement  (MNS)  expressed  in  broad  operational 
terms.  The  MNS  identifies  and  describes  the  mission  deficiency;  discusses  the  results  of 
mission  area  analysis;  describes  why  nonmateriel  changes  (i.e.,  doctrine,  tactics,  etc.)  are 
not  adequate  to  correct  the  deficiency;  identifies  potential  materiel  alternatives;  and  de¬ 
scribes  any  key  boundary  conditions  and  operational  environments,  such  as  logistics 
constraints,  that  may  impact  satisfying  the  need.  The  MNS  is  prepared  in  accordance 
with  CJCS  MOP  77.  System  performance  objectives  and  thresholds  are  developed  from, 
and  remain  consistent  with,  the  initial  broad  statements  of  operational  capability.  The  re¬ 
quirements  are  refined  at  successive  milestone  decision  points,  as  a  consequence  of  cost- 
schedule-performance  tradeoffs  during  each  phase  of  the  acquisition  process. 

In  summary,  all  acquisition  programs  are  based  on  identified,  documented,  and  validated 
mission  needs.  Mission  needs,  which  result  from  ongoing  assessments  of  current  and  pro¬ 
jected  capability,  may  be  designed  to  establish  a  new  operational  capability,  improve  an 
existing  capability,  or  exploit  an  opportunity  to  reduce  costs  or  enhance  performance. 

5.2.1  Cost  Objectives 

Upon  approval  of  the  MNS,  an  approach  is  formulated  to  set  and  refine  cost  objectives. 
Through  consideration  of  projected  out-year  resources,  recent  unit  costs,  parametric  esti¬ 
mates,  mission  effectiveness  analysis  and  trades,  and  technology  trends,  each  ACAT I  and 
ACAT  lA  PM  establishes  life-cycle  cost  objectives  for  the  program  by  program  initiation 
(usually  Milestone  I). 

5.2.2  Evaluation  of  Requirements  Based  on  Commercial  Market  Potential 

Researching  the  potential  of  the  commercial  marketplace  to  meet  system  performance  re¬ 
quirements  is  an  essential  element  of  budding  a  sound  set  of  requirements.  In  developing 
system  performance  requirements,  DoD  Components  evaluate  how  the  desired  perform¬ 
ance  requirements  could  reasonably  be  modified  to  facilitate  the  use  of  potential  commer¬ 
cial  items,  components,  specifications,  standards,  processes,  technology,  and  sources.  The 
results  of  the  evaluation  are  included  as  part  of  the  initial  Operational  Requirements 
Document  (ORD). 

5.3  OPERATIONAL  REQUIREMENTS  DOCUMENT 
5.3.1  Operation  Requirements  Document  (ORD) 

At  each  milestone,  beginning  with  program  initiation  (usually  Milestone  I),  thresholds  and 
objectives  initially  expressed  as  measures  of  effectiveness  or  performance  and  minimum 
acceptable  requirements  for  the  proposed  concept  or  system  are  documented  by  the  user 
or  user's  representative  in  an  Operational  Requirements  Document  (ORD).  Thresholds 
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and  objectives  in  the  ORD  consider  the  results  of  the  analysis  of  alternatives  and  the  im¬ 
pact  of  affordability  constraints.  Key  Performance  Parameters  (KPPs),  validated  by  the 
JROC,  are  included  in  the  appropriate  Acquisition  Program  Baseline  (APB).  A  KPP  is  the 
capability  or  characteristic  that  is  so  significant  that  failure  to  meet  the  threshold  can  be 
cause  for  the  concept  or  system  selection  to  be  reevaluated  or  the  program  to  be  reas¬ 
sessed  or  terminated.  KPPs  are  extracted  from  the  ORD  and  included  in  the  APB.  Thus, 
user  or  user  representative  participation  in  each  acquisition  phase  is  essential. 

Thresholds  and  objectives  are  defined  below.  The  values  for  an  objective  or  threshold  and 
definitions  for  any  specific  parameter  contained  in  the  ORD,  TEMP,  and  APB  shall  be 
consistent. 

5.3. 1 . 1  Threshold.  The  threshold  value  is  the  minimally  acceptable  value  that,  in  the 
user's  judgment,  is  necessary  to  satisfy  the  need.  If  threshold  values  are  not  achieved, 
program  performance  is  seriously  degraded,  the  program  may  be  too  costly,  or  the  pro¬ 
gram  may  no  longer  be  timely.  The  spread  between  objective  and  threshold  values  is  indi¬ 
vidually  set  for  each  program  based  on  the  characteristics  of  the  program  (e.g.,  maturity, 
risk,  etc.). 

5.3. 1.2  Objective.  The  objective  value  is  what  the  user  desires  and  what  the  PM  is  at¬ 
tempting  to  obtain.  The  objective  value  could  represent  an  operationally  meaningful,  time 
critical,  and  cost-effective  increment  above  the  threshold  for  each  program  parameter. 
Program  objectives  (parameters  and  values)  may  be  refined  based  on  the  results  of  the 
preceding  program  phase(s). 

5.3.2  Format  for  the  Operational  Requirements  Document 

Appendix  11  of  DoD  5000.2-R  provides  a  mandatory  format  for  the  ORD  for  use  in 
ACAT I  and  lA  programs  as  mandated  by  that  regulation  as  well  as  CJCS  MOP-77.  The 
operational  performance  parameters  in  the  initial  ORD  is  tailored  to  the  concept  (e.g.,  sat¬ 
ellite,  aircraft,  shop,  missile,  or  weapon,  etc.)  and  reflects  system-level  performance  capa¬ 
bilities,  such  as  range,  probability  of  kiU,  platform  survivability,  operational  availability, 
etc.  Objectives  should  also  be  established  for  each  parameter  and  shall  represent  a  meas¬ 
urable,  beneficial  increment  in  operational  capability  or  operations  and  support.  Table  5A 
shows  the  logistics  and  readiness  portion  of  the  mandatory  format.  Note  that  all  of  the 
logistics  (or  support)  elements  are  addressed  in  Chapter  7  of  this  document. 
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TABLE  5A 


MANDATORY  FORMAT:  OPERATIONAL  REQUIREMENTS 
DOCUMENT  (ORD)  —  (LOGISTICS  EXCERPTS) 


4.  Capabilities  (Operational  Performance  Parameters)  Required: 

-  Objectives,  if  stated,  should  represent  a  measurable,  beneficial 
increase  in  capability  or  operations  and  support  above  the  threshold. 

4b.  Logistics  &  Readiness: 

-  Operational  Availability  &  Mission-Capable  Rate  Measures 

-  Frequency  &  Duration  of  Preventive  or  Scheduled  Maintenance  Actions 

-  Combat  Support  Requirements  (expected  maintenance  levels,  mobility, 
etc.) 

5a.  Maintenance  Planning: 

-  Identify  Maintenance  tasks  &  time  phasing  for  all  maintenance  levels 

-  Describe  planning  approach  for  contract  vs.  organic  repair 

5b.  Support  Equipment: 

-  Define  Standard  Support  Equipment  to  be  used  by  the  system 

-  Describe  test  &  fault  isolation  capabilities  of  Automated  Test  Equipment 
(ATE)  at  all  levels 

5c.  Human  Systems  Integration: 

-  Establish  broad  manpower  requirements  for  operators,  maintainers,  and 
support  personnel 

-  Describe  training  concept  (simulators,  training  device,  embedded  train¬ 
ing,  training  logistics) 

5d.  Computer  Resources: 

-  Describe  the  capabilities  desired  for  integrated  computer  resources 
support. 

5e.  Other  Logistics  Considerations: 

-  Describe  provisioning  strategy 

-  Specify  unique  facility/shelter/environmental  compliance  requirements 

-  Identify  special  packaging/handling/transportation  considerations 

-  Define  unique  data  requirements 
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PROGRAM,  LOGISTICS,  AND  RISK 
MANAGEMENT 


Never  too  early  to  start  logistics! 

Cardinal  rule 


6.1  POLICY 

6.1.1  Program  Tailoring 

AU  programs,  including  highly  sensitive  classified,  cryptologic,  and  intelligence  programs, 
shall  accomplish  certain  core  activities  (described  in  DoDD  5000.1).  These  activities  are 
tailored  to  minimize  the  time  it  takes  to  satisfy  an  identified  need  consistent  with  common 
sense  and  sound  business  practice.  Some  activities  apply  to  Acquisition  Category  (ACAT 
I)  programs  only,  not  to  ACAT  II  and  III  programs.  Other  important  key  activities  for 
each  phase  will  be  applied  on  a  program-by-program  basis  through  the  (Integrated  Prod¬ 
uct  Team)  IPT  process. 

Tailoring  gives  full  consideration  to  applicable  statutes.  Figure  6-1  depicts  the  major 
functions  in  the  life-cycle  acquisition  process.  The  number  of  phases  and  decision  points 
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Figure  6-1:  The  Generic  Life-Cycle  Process 
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can  be  tailored  to  meet  the  specific  needs  of  individual  Program  Managers  (PMs)  and  their 
Milestone  Decision  Authority  (MDA),  based  on  objective  assessments  of  a  program’s 
category  status,  risks,  the  adequacy  of  proposed  risk  management  plans,  and  the  urgency 
of  the  user's  need.  Tailored  acquisition  strategies  may  vary  the  way  in  which  core  activi¬ 
ties  are  to  be  conducted,  the  formality  of  reviews  and  documentation,  and  the  need  for 
other  supporting  activities. 

6.1.2  Determining  Mission  Needs  and  Identifying  Deficiencies 
Refer  to  Section  5.1.1  in  the  previous  chapter. 

6.1.3  Phase  0;  Concept  Exploration 


Phase  0  typically  consists  of  con^etitive,  parallel,  short-term  concept  studies.  The  focus 
of  these  efforts  is  to  define  and  evaluate  the  feasibihty  of  alternative  concepts  and  to  pro¬ 
vide  a  basis  for  assessing  the  relative  merits  (i.  e.  advantages  and  disadvantages,  degree  of 
risk)  of  these  concepts  at  the  next  milestone  decision  point.  Analysis  of  alternatives  shall 
be  used  as  appropriate  to  facilitate  conq)arisons  of  alternative  concepts.  The  most  prom¬ 
ising  system  concepts  shall  be  defined  in  terms  of  initial,  broad  objectives  for  cost,  sched¬ 
ule,  performance,  software  requirements,  opportunities  for  tradeoffs,  overall  acquisition 
strategy,  and  test  and  evaluation  strategy. 

6.1.4  Phase  I;  Program  Definition  and  Risk  Reduction 

During  this  phase,  the  program  shall  become  defined  as  one  or  more  concepts,  design  ap¬ 
proaches,  and/or  parallel  technologies  that  are  pursued  as  warranted.  Assessments  of  the 
advantages  and  disadvantages  of  alternative  concepts  shall  be  refined.  Prototyping,  dem¬ 
onstrations,  and  early  operational  assessments  shall  be  considered  and  included  as  neces¬ 
sary  to  reduce  risk  so  that  technology,  manufacturing,  and  support  risks  are  well  in  hand 
before  the  next  decision  point.  Cost  drivers,  life-cycle  cost  estunates,  cost-performance 
trades,  interoperabihty,  and  acquisition  strategy  alternatives  are  considered  including  evo¬ 
lutionary  and  incremental  software  development. 

6.1.5  Phase  11;  Engineering  and  Manufacturing  Development 

The  primary  objectives  of  this  phase  are  to  translate  the  most  promising  design  approach 
into  a  stable,  interoperable,  producible,  supportable,  and  cost-effective  design;  validate  the 
manufacturing  or  production  process;  and  demonstrate  system  capabilities  through  testing. 
Lx)w  Rate  Initial  Production  (LRIP)  occurs  while  the  Engineering  and  Manufacturing  De¬ 
velopment  (EMD)  phase  is  stih  continuing  as  test  results  and  design  fixes  or  upgrades  are 
incorporated. 
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6.1.6  Low  Rate  Initial  Production^ 

The  objective  of  this  activity  is  to  produce  the  minimum  quantity  necessary  to  provide: 

•  production-configured,  or  representative,  articles  for  operational  tests; 

•  an  initial  production  base  for  the  system;  and 

•  an  orderly  increase  in  the  system  production  rate  that  is  sufficient  to  lead  to 
full-rate  production  upon  successful  completion  of  operational  testing. 

LRIP  quantities  for  all  ACATs  shall  be  minimized.  The  MDA  shall  determine  the  LRIP 
quantity  (10  USC  (24004))  for  all  Acquisition  Category  (ACAT)  I  and  II  programs  as  part 
of  the  Engineering  and  Manufacturing  Development  (EMD)  approval.  The  LRIP  quantity 
(with  rationale  for  quantities  exceeding  10  percent  of  the  total  production  quantity  docu¬ 
mented  in  the  acquisition  strategy)  is  included  in  the  first  Selected  Acquisition  Report 
(SAR)  after  its  determination.  The  LRIP  quantity  shall  not  be  less  than  one  unit,  and  any 
increase  shall  be  approved  by  the  MDA.  When  approved  LRIP  quantities  are  expected  to 
be  exceeded  because  the  program  has  not  yet  demonstrated  readiness  to  proceed  to  full- 
rate  production,  the  MDA  assesses  the  cost  and  benefits  of  a  break  in  production  versus 
annual  buys. 

Note:  The  Director,  Operational  Test  and  Evaluation  (DOT&E),  is  the  decision  authority 
for  the  number  of  LRIP  articles  required  for  Initial  Operational  Test  and  Evaluation 
(lOT&E)  and  for  Live  Fire  Test  and  Evaluation  (LFT&E). 

6.1.7  Phase  III:  Production,  Fielding/Deployment,  and  Operational  Support 

The  objective  of  the  Production,  Fielding/Deployment,  and  Operational  Support  phase  is 
to  achieve  an  operational  capability  that  satisfies  mission  needs.  Deficiencies  encountered 
in  Developmental  Test  and  Evaluation  (DT&E)  and  lOT&E  are  resolved  and  fixes  veri¬ 
fied.  The  production  requirement  of  this  phase  does  not  apply  to  ACAT  lA  acquisition 
programs  or  software-intensive  systems  with  no  developmental  hardware  components. 
During  fielding/deployment  and  throughout  operational  support,  the  potential  for  modifi¬ 
cations  to  the  fielded/deployed  system  continues. 

6. 1.7.1  Production.  Chapter  24  of  this  guide  is  devoted  to  the  subject  of  production  and 
the  logistics  planning  and  testing  associated  with  that  phase. 

6. 1.7.2  Deplovment/Fielding.  The  term  “deployment,”  as  used  here,  includes  fielding, 
turnover,  hand-off,  fleet  introduction,  and  other  terms  used  by  the  Services  for  the  initial 
introduction  of  a  system  to  operational  commands.  Included  are  deployment  planning. 
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LRIP  is  not  applicable  to  ACAT  LA  programs;  however,  a  limited  deployment  phase  may  be  applicable. 
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execution,  and  follow-up  requirements  covering  each  of  the  logistics  elements  during  the 
acquisition  periods  from  Concept  Exploration  (CE)  until  the  last  unit  is  operational. 

Chapter  7  of  this  Guide  is  devoted  to  a  description  of  the  logistics  element,  and  Chapter 
25  is  devoted  to  the  subject  of  deployment/fielding. 

6.1.8  Operational  Support 

The  objectives  of  this  activity  are  the  execution  of  a  support  program  that  meets  the 
threshold  values  of  all  support  performance  requirements  and  sustainment  of  them  in  the 
most  cost-effective  manner  over  the  life  cycle.  A  foUow-on  operational  testing  program 
that  assesses  performance,  quality,  compatibility,  and  interoperability  and  that  identifies 
deficiencies  shall  be  conducted  as  appropriate.  This  activity  shall  also  include  the  execu¬ 
tion  of  operational  support  plans,  including  the  transition  from  contractor  to  organic  sup¬ 
port,  if  appropriate. 

6.1.9  Modifications 

Any  modification  that  is  of  sufficient  cost  and  complexity  and  that  could  itself  qualify 
as  an  ACAT  I  or  ACAT  lA  program  is  considered  for  management  purposes  as  a 
separate  acquisition  effort.  Modifications  that  do  not  cross  the  ACAT  I  or  lA 
threshold  are  considered  part  of  the  program  being  modified.  Modifications  may 
cause  a  program  baseline  deviation.  Deviations  shall  be  reported  using  the  procedures 
in  Part  6  of  DoD  5000.2-R. 

6.1.10  Demilitarization  and  Disposal 

At  the  end  of  its  useful  life,  a  system  must  be  demilitarized,  disposed,  or  recycled.  During 
demilitarization  and  disposal,  the  PM  ensures  that  materiel  determined  to  require  demilita¬ 
rization  is  controlled  and  that  disposal  is  carried  out  in  a  way  that  minimizes  DoD's  liability 
due  to  environmental,  safety,  security,  and  health  issues. 

6.2  PRODUCT  DEFINITION 

Product  definition  is  the  common  thread  linking  all  acquisition  disciplines.  In  the  current 
environment  of  near-full  dependence  on  performance  and  commercial  specifications,  pro¬ 
gram  management  faces  a  significant  challenge  in  making  sure  that  the  product  is  clearly 
defined,  because  of  the  following  factors: 

•  Program  planning  must  know  what  to  plan  for. 

•  System  engineering  and  software  must  know  what  to  design. 

•  The  test  community  must  know  what  to  test. 

•  The  producer  must  know  what  to  manufacture. 
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•  The  logistics  community  must  know  what  to  support. 

•  Contract  management  must  know  what  to  buy. 

•  Cost  management  must  know  what  to  estimate  and  control. 

•  Funds  management  must  know  what  to  budget. 


6.3  TIME-PHASED  SUPPORT  ACTIVITIES 


Figure  6-2  displays  the  defense  systems  acquisition  management  process,  showing  the  key 
management  activities  associated  with  each  phase  of  the  acquisition  process.  Correspond¬ 
ingly,  the  paragraphs  immediately  below  (6.3.1  through  6.3.4)  outline  the  major  activities 
of  the  Logistics  Manager  (LM)  up  to  and  including  the  HMD  program  phase.  Subsequent 
chapters  of  this  guide  provide  information  regarding  zictivities  associated  with  Production 
(Chapter  24),  Fielding/Deployment  (Chapter  25),  Postproduction  Support  (Chapter  27), 
and  Disposal/Recycling/Demilitarization  (Chapter  29).  Figure  6-3  displays  the  logistics 
management  activities  that  take  place  within  the  larger  defense  systems  acquisition  man¬ 
agement  process  displayed  in  Figure  6-2. 

6.3.1  Prior  To  Milestone  0 

Prior  to  Milestone  0,  the  major  preprogram  effort  is  the  preparation  of  a  Mission 
Needs  Statement  (MNS).  The  MNS  should  identify  all  logistics  support  constraints. 
In  order  to  derive  the  constraints,  the  LM  should  investigate  lessons  learned  and  im¬ 
provement  targets  on  existing  like  and  similar  systems  and  equipment.  Also,  the  LM 
should  identify  potential  logistics  technologies,  perform  early  support  analysis  activi¬ 
ties  at  the  system  level,  and  assess  alternative  acquisition  logistics  strategies.  In  sum¬ 
mary,  the  functions  to  be  performed  prior  to  Milestone  0  are  to: 

•  include  logistics  support  constraints  in  the  MNS; 

•  investigate  lessons  learned  and  improvement  targets; 

•  identify  potential  logistics  technologies; 

•  assess  alternative  acquisition  logistics  strategies;  and 

•  perform  early  support  analysis  activities,  such  as  developing  a  support  concept. 
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Figure  6-3:  Acquisition  Logistics  Management  Activities 


6.3.2  Phase  0  -  Concept  Exploration 

At  this  stage,  no  program  or  program  office  exists  per  se;  but  alternative  concepts  are  be¬ 
ing  analyzed  to  satisfy  the  requirements  of  the  MNS.  A  major  planning  effort  is  underway 
by  a  program  office  cadre  to  prepare  for  program  initiation  at  Milestone  I.  The  LM 
should: 

•  develop  the  acquisition  logistics  strategy; 

•  refine  initial  supportability  planning  and  Life  Cycle  Cost  (LCC)  estimates; 

•  keep  in  step  with  emerging  design; 

•  provide  logistics  involvement  in  PDRR  contract  management  and  Integrated 
Product  Team  (IPT)  reviews; 

•  prepare  logistics  section  of  EMD  contract  package;  and 

•  consider  support  analyses,  such  as  Standardization  and  Interoperability. 

6.3.3  Phase  I  -  Program  Definition  and  Risk  Reduction 

In  this  phase,  principal  program  office  activity  centers  on  evaluating  system  alternatives; 
selecting  preferred  system  altemative(s);  defining  the  critical  design  characteristics  and 
capabilities;  and  demonstrating  that  the  required  technologies  can  be  incorporated  into  the 
system  design.  The  LM  will  focus  on  the  following  tasks  during  this  phase: 

•  implementing  acquisition  logistics  strategy; 

•  refining  initial  supportability  planning  and  LCC  estimates; 

•  keeping  in  step  with  emerging  design; 

•  providing  logistics  involvement  in  PDRR  contract  management  and  IPT 
reviews; 

•  preparing  logistics  section  of  EMD  contract  package; 

•  considering  support  analyses,  such  as  standardization  and  interoperability;  and 

•  initiating  postproduction  planning. 
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6.3.4  Phase  11  -  Engineering  and  Manufacturing  Development 

The  major  activity  of  the  PM  is  associated  with  translating  the  design  approach  into  a  sta¬ 
ble,  producible,  and  cost-effective  system  design  and,  through  developmental  and  opera- 
tiond  testing,  demonstrating  that  the  system  meets  specification  requirements,  satisfies  the 
mission  need,  and  meets  minimally  acceptable  peacetime  and  wartime  requirements.  The 
main  thrust  of  test  programs  is  to  e”  Juate  system-level  performance.  However,  the  LM 
must  build  into  the  test  program  structure  additional  assessments  of  component  evaluation 
and  the  adequacy  of  the  logistics  elements  that  comprise  the  logistics  support  structure. 
Further,  the  LM  should  work  closely  with  the  Program  Management  Office  (PMO)  and 
appropriate  IPTs  to  accomplish  the  following: 

•  inclement  acquisition  logistics  strategy; 

•  continue  to  refine  supportability  planning  and  LCC  estimates; 

•  commence  Test  and  Evaluation  (T&E)  of  logistics; 

•  continue  logistics  involvement  in  EMD  contract  management  and  IPT  reviews; 

•  prepare  the  logistics  sections  of  the  Next-phase  contract  package;  and 

•  consider  support  analyses,  such  as  finalizing  postproduction  support  plans. 

6.4  RISK  MANAGEMENT 


Risk  is  inherent  in  any  acquisition  program  and  in  virtually  all  functional  areas  of  a  pro¬ 
gram,  including  the  area  of  logistics.  The  LM  and  other  functional  experts  at  all  levels 
must  address  the  areas  of  risk  to  ensure  that  program  objectives  are  met.  Risk  manage¬ 
ment  is  a  program  management  responsibility  and  is  the  act  or  practice  of  controlling  risk 
drivers  that  adversely  affect  the  program.  It  includes  the  process  of  identifying,  analyzing, 
and  tracking  risk  drivers;  assessing  the  likelihood  of  their  occurrence  and  their  conse¬ 
quences;  defining  risk-handling  plans;  implementing  these  plans;  and  performing  continu¬ 
ous  assessments  to  determine  how  risks  change  during  the  life  of  the  program.  Risk  man¬ 
agement  requires  aU  process  participants  to  use  a  disciplined  approach  so  that  an  accept¬ 
able  level  of  program  risk  is  achieved  and  maintained.  This  is  done  by  controlling  the  risks 
associated  with  the  design,  manufacturing,  technology,  test,  and  support  functions  that  are 
part  of  systems  acquisition. 

A  good  risk  management  program  can  enhance  program  management  effectiveness  and 
provide  managers  with  an  important  tool  for  reducing  a  system's  life-cycle  costs.  A  de¬ 
scription  of  the  risk  management  plan  is  an  essential  part  of  the  program  strategy.  Effec¬ 
tive  risk  management  depends  on  a  thorough  understanding  of  the  concept  of  risk,  the 
principles  of  risk  management,  and  the  establishment  of  a  disciplined  risk  management 
process.  DoD  policy  does  not  mandate  a  specific  approach  to  risk  management.  In  the 
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past,  aggressive  performance  requirements  would  drive  technical,  cost,  and  schedule  risks. 
Under  the  Cost  As  an  Independent  Variable  (CAIV)  concept,  the  emphasis  is  reversed; 
and  aggressive  cost  objectives  can  drive  performance  and  schedule  requirements  and  risks. 
Moreover,  in  coordination  with  the  user,  requirements  may  be  reduced  or  eliminated  so 
risk  is  reduced  to  a  level  that  increases  the  likelihood  of  meeting  cost  objectives.  By  es¬ 
tablishing  an  effective  risk  management  program,  PMs  may  design  and  control  their  pro¬ 
grams  by  using  information  about  risk  areas  to  set  objectives,  develop  acquisition  strate¬ 
gies  to  mitigate  risk,  and  identify  metrics  that  allow  continual  tracking  and  assessment  of 
the  program.  This  process  includes  risk  planning,  assessing  risk  areas,  developing  risk¬ 
handling  options,  monitoring  risks  to  determine  how  risks  have  changed,  and  documenting 
the  overall  risk  management  progrant 

6.4.1  Managing  Support  Risks 

The  Logistics  Manager  (LM)  must  focus  on  the  support  risk  as  well  as  risks  associated 
with  cost  and  schedule.  Key  support  risks  are  those  associated  with: 

•  achieving  reliability,  availability,  and  maintainability  goals; 

•  achieving  an  effective  logistics  support  structure;  and 

•  successfully  deploying/fielding  the  system. 

Cost  and  schedule  risks  are  largely  associated  with  the  accuracy  of  the  cost  and  schedule 
estimating  processes  and  their  supporting  assunptions  as  well  as  risk  associated  with  bot¬ 
tlenecking  events  or  a  high  degree  of  concurrency.  Both  tend  to  create  multiple  critical 
paths  in  the  work  effort. 

To  effectively  manage  the  pertinent  risks,  the  LM  must  understand: 

•  what  adverse  events  may  occur; 

•  the  likelihood  (probability)  of  each  event  occurring;  and 

•  the  severity  of  the  cost,  schedule,  and  performance  impacts  of  each  event. 

Given  this  level  of  understanding,  the  manager  is  in  a  position  to  seek  ways  to  do  one  or 
more  of  the  following: 

•  make  it  less  likely  that  the  risk  event  will  occur; 

•  deal  with  the  cost,  schedule,  and  performance  effects  of  the  risk  event  in  ways 
that  minimize  damage  to  the  program;  and/or 
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•  decide  to  accept  the  risk  as  reasonable  given  the  cost,  schedule,  and  perform¬ 
ance  advantages  of  the  acquisition  strategy  and  the  program’s  requirements. 

6.4.2  Risk  Management  in  CATV 

The  following  list  provides  key  areas  of  risk  that  must  be  addressed  in  a  “formal  risk”  ef¬ 
fort  within  a  program  as  a  part  of  the  CAIV  process.  Such  a  risk  effort  must  have  dedi¬ 
cated  program  office  assigned  resources  in  order  to  implement  CAIV.  Some  of  these  risks 
are  in  conflict  with  others  and  a  continual  balancing  of  these  risks  is  required.  Bad  news 
should  be  allowed  to  surface;  the  manager  should  always  know  the  worst  thing  that  can 
happen  to  the  program.  The  process,  as  noted  earlier,  is  an  iterative  one;  and  the  risks 
come  into  play  multiple  times  during  the  life  of  the  program  Risks  to  watch; 

•  The  program  is  broken  into  manageable  elements.  The  attention  to  costs  re¬ 
quired  by  CAIV  makes  it  essential  that  the  government  PM  has  manageable 
elements  for  the  entire  program  These  elements  must  have  metrics  so  the  ac- 
con:q)anying  risks  can  be  measured,  assessed,  and  managed  for  each  element 
and  the  entire  program 

•  To  provide  realistic  system  affordability,  the  current  budget  and  priority  deci¬ 
sions  for  a  system  are  sufficiently  accurate  and  remain  stable  over  the  program 
life  cycle.  The  program  budget  must  be  realistic  and  stable  for  a  successful 
program  This  is  a  major  problem  in  managing  most  acquisition  programs.  It 
is  even  more  critical  under  CAIV,  where  cost  explicitly  drives  performance  and 
schedule.  Keep  cost  off  the  critical  path  through  daily  management  by  key  in¬ 
dividuals. 

•  The  threshold  performance  requirements  will  provide  the  necessary  mission 
effectiveness  and  will  be  stable  during  system  development  and  production. 
Risks  are  the  differences  between  threshold  and  objective  requirements  that 
provide  sufficient  tradeoffs  between  cost,  schedule,  and  performance.  The  bal¬ 
ance  between  ensuring  that  the  system  will  meet  the  users  true  requirements 
and  the  necessity  that  the  threshold  requirement  will  be  sufficiently  low  that 
real  trade  space  exists  between  the  threshold  and  objective  is  critical  to  the 
tradeoff  process. 

•  The  shape  of  the  function  relating  performance,  schedule,  requirement(s),  mis¬ 
sion  effectiveness,  and  cost  can  be  determined  and  subsequently  utilized  m 
tradeoff  analyses.  The  determination  of  this  function  and  the  desire  to  find  the 
“knee  of  the  curve”  will  require  not  only  good  cost  data  but  also  extensive 
modeling  of  mission  effectiveness.  An  excellent  example  is  the  work  of  the  F- 
22  Aircraft  Program  in  modeling  these  relationships. 

•  The  historical  database  for  parametric  estimates  used  in  cost-effectiveness  as¬ 
sessment  is  sufficiently  appheable  to  the  system  being  estimated  to  provide  an 
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accurate,  most  likely  value  and  range  (or  probability  distribution  fiinction)  for 
the  costs  of  the  system.  The  database  for  parametric  estimates  seems  to  be  al¬ 
ways  populated  with  programs  that  are  sufficiently  different  in  technology,  de¬ 
sign,  or  mission  from  the  program  that  the  validity  of  the  estimate  is  in  ques¬ 
tion.  Further,  there  is  almost  no  data  linked  to  acquisition  reform  that  reflects 
the  cost  savings  within  both  government  and  industry.  For  good  tradeoffs  to 
be  possible,  good  cost  models,  with  valid  data  reflecting  the  current  cost  iiiitia- 
tives,  must  be  available.  The  Under  Secretary  of  Defense  for  Acquisition  and 
Technology  (USD(A&T))  has  pointed  out  that  much  work  remains  to  be  done 
in  the  area  of  cost  modeling  in  support  of  CAIV. 

•  The  interrelationships  of  the  system  performance  requirements  are  sufficiently 
understood  to  select  tb.e  most  cost-effective  system  performance  objectives. 
Performance  requirements  and  schedule  must  be  accurately  translated  into 
contractual  goals  the  contractor  has  sufficient  incentive  to  achieve.  System 
performance  goals  are  seldom  independent.  The  schedule  can  be  linked  to  cost 
and  mission.  Understanding  these  interrelationships  is  critical  to  contracting 
with,  and  giving  incentive  to,  the  contractor. 

•  Technology  developments  wiU  enable  specific  design  and  process  decisions  to 
be  achieved.  If  the  performance  requirements  have  been  too  ambitious  and 
they  do  not  become  achievable,  the  cost  and  schedule  of  technology  develop¬ 
ment  will  become  the  drivers. 

The  central  feature  of  CAIV  is  the  tradeoff  process.  This  process  of  determining  afford¬ 
able  performance  and  scheduling  based  on  cost  goals  is  accomplished  by  a  set  of  decisions 
that  balance  the  above  risks. 

6.4.3  Risk  Management  in  Joint  Programs 

In  many  ways,  program  management  is  risk  management;  and  joint  programs  add  to  the 
number  of  risks  facing  the  joint  PM.  By  definition,  the  joint  PM  has  multiple  users, 
requirements  and  funding  sources.  These  customers  can  adversely  affect  the  health  of  the 
program  by  raising  issues  related  to  system  requirements,  funding  variations,  or  political 
nuances  within  the  program.  A  common  issue  is  the  degree  and  effectiveness  of 
interoperability  of  the  new  system  with  participating  Component  systems.  Accordingly, 
the  joint  PM  should  be  careful  to  monitor  technical  risks  in  order  to  help  maintain  program 
consensus  and  ensure  proper  interoperability. 

6.4.3. 1  Logistics  Risk  Areas  in  Joint  Programs.  Logistics  planning  for  joint  programs 
requires  more  coordination  than  that  required  for  single-Service  programs.  No  other 
aspect  of  joint  program  management  wiU  confront  the  manager  with  as  many  inter-Service 
differences  as  logistics.  Differences  can  occur  in  aU  of  the  logistics  elements.  The  lack  of 
extensive  coordination  can  lead  to: 
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•  incomplete  or  inadequate  logistics  support  at  the  time  of  initial  deployment; 

•  a  decision  by  one  or  more  Services  to  go  it  alone  with  logistics  planning  and 
development  of  Service-unique  logistics  support;  and 

•  loss  of  the  economies  that  can  be  gained  by  joint-logistics  performance. 

6.4.3.2  Risk  Handling.  Success  in  joint  program  management  comes  from  facilitating  and 
expediting  the  required  coordination,  not  from  eliminating  coordination  and  fragmenting 
the  program.  Methods  that  have  been  employed  include: 

•  Early  Recognition  of  Joint  Requirements.  During  mission  area  analysis,  a  vital 
first  step  is  early  recognition  that  a  joint  program  is  needed.  OSD,  the  Joint 
Chiefs  of  Staff  (JCS),  or  two  or  more  Services  in  unison  may  initiate  the  joint 
MNS.  When  this  occurs,  a  joint  program  structure  is  recommended  in  the 
MNS;  funding  requirements  for  each  Service  are  identified  in  each  Service's 
initial  Program  Objectives  Memorandum;  and  common  and  unique 
requirements  of  the  Services  are  documented  in  the  initial  joint  Logistics  Plan 
prepared  during  CE. 

•  Staffing  of  the  Joint  Program  Office.  Senior  representatives  and  other 
participating  Service  personnel  serve  two  vital  functions.  First,  they  work  as 
part  of  a  team  committed  to  objectives  of  the  joint  program.  Second,  they  are 
conduits  for  rapid  two-way  communications  and  decisions  on  methods  to 
implement  joint  planning  and  satisfy  unique  needs  of  each  Service. 

•  Effective  Communication.  Inplementationofjoint  logistics  planning  by  the 
Services  requires  participation  by  their  subordinate  activities.  Effective 
communications  must  be  carried  out  among  the  provisioners,  maintenance 
engineers,  publication  managers,  trainers,  and  other  logisticians  who  support 
the  program  within  the  Services.  The  lead  LM  must  ensure  that  key  logistics 
personnel  from  each  Service  are  identified  and  that  they  jointly  participate  in 
planning  and  establishing  the  program.  A  hierarchy  consisting  of  a  high-level 
review  team,  a  joint  logistics  committee,  and  functional  working  groups  may 
be  established  to  provide  oversight  and  rapid  decisions  that  meet  each  Service's 
needs. 

•  Incremental  Development  Techniques.  Preplanned  Product  Improvement 
provisions,  evolutionary  development,  and  other  incremental  development 
techniques,  especially  if  coordinated  with  user  commands,  can  split 
development  problems  into  small  increments  and  defer  large  risks.  The  use  of 
standard  software  and  software  reuse  can  also  minimize  software  and  program 
development  risks.  The  Logistics  IPT  must  closely  monitor  the  program 
cost/design/performance  tradeoffs  to  evaluate  the  logistics  impacts  on  each  of 
the  Component  support  programs. 
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6.4.4  Reference 


For  more  information  regarding  risk  management  tools  and  techniques,  the  reader  is  re¬ 
ferred  to  the  Teaching  Note  entitled,  “Program  Risk  Management,”  by  W.  W.  Bahmnaier 
and  Paul  McMahon,  Defense  Systems  Management  College,  Oct.  8, 1996. 
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7 

SUPPORT  ELEMENTS 

“I  don’t  know  what  the  hell  this  “logistics”  is  that  [General] 

Marshall  is  talking  about,  but  I  want  some  of  it.  ” 

Admiral  Ernest  J.  King, 
during  World  War  II 

7.1  BACKGROUND 

The  DSMC’s  Glossary  of  Defense  Acquisition  Acronyms  and  Terms  (May  1997),  de¬ 
fines  acquisition  logistics  as  technical  and  management  activities  that  ensure  supportability  im¬ 
plications  are  considered  early  and  throughout  the  acquisition  process  to  minimize  support 
costs  and  that  provide  the  user  with  the  resources  to  sustain  the  system  in  the  field. 

One  of  the  best  management  techniques  for  addressing  all  aspects  of  logistics  is  to  use  a 
“checklist”  of  logistics  elements  (sometimes  called  “support  elements”).  Figure  7-1  de¬ 
picts  the  ten  logistics  support  elements.  Addressing  each  of  these  elements  is  the  surest 
way  to  identify  the  supportability  in^lications  of  your  system.  The  following  traditional 
logistics  elements  constitute  the  support  infrastructure  that  should  be  addressed  (including 
both  hardware  and  software  considerations)  over  the  system  life  cycle  under  both  peace¬ 
time  and  wartime  conditions. 


Figure  7-1;  The  Logistics  Elements 
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Before  addressing  each  of  the  logistics  elements  in  turn,  a  word  of  caution  is  in  order.  The 
DoD  movement  toward  the  use  of  commercial  specifications,  best  practices,  and  perform¬ 
ance  specifications  demands  that  support  requirements,  as  stated  in  formal  program  docu¬ 
mentation,  be  addressed  in  terms  of  program  performance  specifications  as  opposed  to 
addressing  distinct  logistics  elements.  Specifically,  the  support  requirements  should  relate 
to  a  system’s  operational  effectiveness,  operational  suitability,  and  life-cycle  cost  reduc¬ 
tion.  This  approach  is  specified  in  Section  2.6  of  DoD  50(X).2-R.  Therefore,  the  tradeoffs 
involved  in  the  early  phases  of  design  development  must  consider  logistics  elements  and 
system  design  elements  in  a  closely  integrated  fashion  in  order  to  achieve  the  overall  sys¬ 
tem  goals. 

7.2  MAINTENANCE  PLANNING 

Maintenance  planning  is  the  process  conducted  to  develop  and  establish  maintenance  and 
support  concepts  and  requirements  for  the  lifetime  of  the  defense  system.  It  answers 
questions  such  as  the  following:  What  can  go  wrong?  Who  will  fix  it?  Where  will  it  be 
fixed?  How  win  it  be  fixed?  When  will  it  be  fixed?  An  acquisition  program  should  estab¬ 
lish  logistics  support/maintenance  plans  throughout  the  development  process,  with  life- 
cycle  costs  playing  a  key  role  in  this  process.  Support/maintenance  concepts  should  re¬ 
flect  the  optimum  balance  between  readiness  and  life-cycle  cost.  Maintenance  planning  is 
the  logical  starting  point  in  addressing  the  logistics  elements.  If  the  maintenance  plan 
changes,  chances  are  that  many  of  the  other  logistics  elements  will  also  change.  Tradi¬ 
tionally,  there  have  been  three  levels  of  maintenance,  i.e.,  organizational,  intermediate,  and 
depot;  however,  some  systems  or  subsystems  operate  with  two  levels  of  maintenance,  omitting 
the  intermediate  level.  Table  7  A  characterizes  the  activities  performed  at  each  of  the  three 
maintenance  levels. 


Table  7A 

TRADITIONAL  LEVELS  OF  MAINTENANCE 


I 

ORGANIZATIONAL 

n 

INTERMEDIATE* 

m 

DEPOT 

•  On  equipment/system 

•  Between  org.  and  depot 

•  Overhaul/complex  repair 

•  Quick  turnaround 

•  Repair  by  replacement  of 

•  System  and  functional 

•  Repair  by  replacement 

shop  replaceable  units  or 

responsibility 

(LRAAVRA) 

components 

•  Production  line  orientation 

•  Supply  system  support 

*For  Army  “intermediate  ”  includes  Direct  Support  (DS)  and  General  Support  (GS): 

-  DS  -  ~  GS  - 


Repair  by  replacement 
Corps  level 
Hi^  mobility 
Supports  unit  supply 


Repair  down  to  the  component  level 
Echelon  above  corps 
Semi-fixed  facilities 
Supports  theater  supply  systems 
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7.2.1  Maintenance  Concept 

A  maintenance  concept  is  a  general  description  of  the  maintenance  tasks  required  in  sup¬ 
port  of  a  given  system  or  equipment  and  the  designation  of  the  maintenance  level  for  per¬ 
forming  each  task.  The  maintenance  concept  will  normally  be  incorporated  into  the  more 
specific  maintenance  plan. 

7.2.2  Maintenance  Plan 

A  maintenance  plan  is  a  description  of  the  requirements  and  tasks  to  be  accomplished  for 
achieving,  restoring,  or  maintaining  the  operational  capability  of  a  system,  equipment,  or 
facility.  The  maintenance  plan  is  normally  one  of  the  parts  of  the  logistics  support  plan. 

The  irreversible  and  increasing  commitment  of  DoD  to  Automated  Information  Systems 
(AIS)  and  subsystems  requires  maintenance  concepts/plans  to  address  both  hardware  and 
software,  in  order  to  ensure  an  integrated  approach.  However,  the  nature  of  hardware 
maintenance  differs  from  that  of  software  maintenance.  When  hardware  fads,  the  failure  is 
usually  isolated  to  a  faulty  part,  which  can  be  removed  and  replaced.  A  paper  description 
(failure  report)  and  a  faulty  part  are  available  for  inspection  or  further  analysis  by  the 
hardware  depot.  When  software  fails,  only  a  paper  description  (software  trouble  report)  is 
normally  available  for  inspection  and  fiirther  analysis.  Faced  with  a  software  failure,  the 
operator  (who  can  be  thought  of  as  the  organizational  level  of  software  maintenance)  will 
usually  attempt  a  system  restart  or  some  other  type  of  workaround.  The  programming 
support  center  (which  can  be  thought  of  as  the  software  maintenance  depot)  must  dupli¬ 
cate  the  software  failure  on  its  own  equipment  before  commencing  the  process  of  “fixing” 
the  failure. 

Hardware  maintenance  is  relatively  straightforward.  When  it  fads,  the  fadure  is  detected,  a 
bad  part  is  isolated,  and  the  bad  part  is  replaced  with  a  good  part.  Software  maintenance, 
on  the  other  hand,  is  not  so  straightforward.  If  it  fails,  the  software  must  be  redesigned  to 
preclude  a  similar  fadure.  The  rest  of  the  system  may  also  have  to  be  checked  to  assure 
that  fixing  the  fadure  at  hand  does  not  introduce  other  errors  or  potentials  for  fadure  into 
the  system.  A  more  thorough  discussion  of  software  logistics  considerations  is  contained 
in  Chapter  20  of  this  Guide. 

A  significant  danger  in  software  maintenance  arises  from  the  fact  that  product  improve¬ 
ments  and  redesign  are  accomplished  through  exactly  the  same  procedure  as  fadure  re¬ 
pairs.  Because  of  programmers’  natural  tendency  to  “fine  tune”  their  systems  at  every 
stage  and  occasionally  add  more  sophistication  (without  thought  of  cost  or  schedule),  a 
single  error  fix  or  repair  frequently  becomes  an  opportunity  for  much  more  elaborate 
software  engineering.  This  tendency  must  be  carefully  controlled.  Figure  7-2  diagrams  a 
typical  maintenance  concept,  which  includes  both  hardware  and  software. 

Some  of  the  necessary  issues  in  the  first  round  of  maintenance  planning:  Are  organic  sup¬ 
port,  contractor  support,  or  a  combination  of  the  two  caUed  for?  If  contractor  support  is 
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used,  will  it  be  life-cycle  prime  contractor  support  or  competition?  Can  a  prime  contrac¬ 
tor  hardware  and  software  warranty  be  instituted?  What  happens  if  the  operator,  upon 
occurrence  of  a  hardware  or  software  failure,  is  unable  to  work  around  the  problem?  Is 
there  a  manual  backup?  If  not,  are  hardware  and  software  specialists  available  on-call?  It 
is  important  to  remember  that  both  hardware  and  software  must  be  addressed  at  the  same 
time  to  achieve  a  truly  integrated  maintenance  plan. 

For  software  in  particular,  the  development  of  a  life-cycle  management  plan,  with  empha¬ 
sis  on  the  planmng  for  transition  to  the  support  phase,  is  of  paramount  importance,  since 
the  majority  of  the  cost  of  software  (60  to  80  percent)  is  associated  with  post-production 
support. 

7.2.3  Manpower  and  Personnel 

Manpower  and  personnel  is  the  term  used  to  represent  the  people  required  to  operate  and 
support  the  system  (including  its  support)  over  its  planned  life  cycle.  Manpower  and  per¬ 
sonnel  analysis  is  the  process  conducted  to  identify  and  acquire  military  and  civilian  per¬ 
sonnel  with  the  skills  and  grades  required  to  operate  and  support  the  system  over  its 
planned  lifetime  at  both  peacetime  and  wartime  rates.  Acquisition  logistics  efforts  should 
strive  to  minimize  the  quantity  and  skill  levels  of  manpower  and  personnel  required  to  op¬ 
erate  and  support  the  system,  since  manpower  and  personnel  can  be  expected  to  be  a  ma¬ 
jor,  if  not  the  major,  contributor  to  system  life-cycle  cost.  Manpower  and  personnel  cer¬ 
tainly  continue  to  constitute  the  largest  component  of  the  DoD  budget. 

Skill  levels  of  Service  personnel  and  turnover  continue  to  be  significant  problems.  To 
cope  with  this,  DoD  has  been  forced  to  greatly  simplify  man/machine  interfaces  and  utilize 
built-in  test/fault  isolation  devices  to  reduce,  at  least  at  the  organizational  level  of  mainte¬ 
nance,  the  skill  levels  required  of  personnel  who  operate  and  maintain  the  systems.  This 
approach  has  resulted  in  more  complex  and  costly  automated  information  systems  and 
subsystems.  Highly  skilled  individuals  (college  graduates  entering  the  Service,  motivated 
individuals  who  can  be  trained,  etc.)  are  generally  required  to  maintain  the  increasingly  so¬ 
phisticated  types  of  software.  This  trend  toward  more  information  technology  (IT)  con¬ 
tinues  unabated. 

The  unique  characteristics  and  skills  of  individuals  available  now,  and  projected  into  the 
future,  to  operate  and  maintain  AIS  at  aU  levels  must  influence  basic  design  decisions. 
Allocation  of  functions  to  hardware  and  to  software  must  be  logically  made  to  ensure 
compatibility  between  the  required  and  available  individuals.  The  decision  regarding  or¬ 
ganic  versus  contractor  support  of  AIS  must  be  made  early  in  the  program,  and  efforts 
must  be  made  to  gamer  the  required  core  software  logisticians  for  the  program. 
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7.2.4  Supply  Support 


Supply  support  analysis  is  the  process  conducted  to  determine,  acquire,  catalog,  receive, 
store,  transfer,  issue,  and  dispose  of  secondary  items  necessary  for  the  support  of  end 
items  and  support  items  (such  as  support  and  test  equipment,  trainers,  and  simulators)  that 
meet  the  user’s  peacetime  and  wartime  readiness  requirements.  The  process  includes  ini¬ 
tial  support  (provisioning)  and  foUow-on  requirements  (routine  replenishment).  Acquisi¬ 
tion  logistics  efforts  should  strive  to  reduce  the  variety  of  parts  and  maximize  the  stan¬ 
dardization  of  parts  used  in  end  items  and  support  items. 


Figure  7-2:  Typical  Hardware/Software  Maintenance  Concept 

Supply  support  involves  ensuring  that  spares  (hardware  components  and  computer  pro¬ 
grams)  and  repair  parts  required  to  operate  and  maintain  a  system  are  provided  on  a  timely 
basis.  Consumable  or  expendable  items,  such  as  computer  printer  paper,  batteries,  and 
printer  ribbons,  are  also  included  here.  Hardware  supply  support  consists  of  a  provision¬ 
ing  phase  followed  by  routine  replenishment.  Software  supply  support  must  include  soft¬ 
ware  and  firmware  cataloging  and  provision  for,  and  routine  resupply  of,  media  (printer 
paper,  cards,  magnetic  and  paper  tapes,  etc.)  used  to  transfer  or  transport  computer  pro¬ 
grams. 

Standardization  of  hardware  components,  devices,  and  systems  and  their  selection  for  use 
in  new  designs  can  go  a  long  way  toward  reducing  the  costs  of  new  designs  and  the  costs 
and  complexity  of  supply  support.  Software  standardization  is  of  equal  importance. 
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Transportability  of  software  among  a  variety  of  existing  and  future  IT  systems  is  an  im¬ 
portant  issue. 

When  hardware  fails,  an  already  designed  replacement  is  drawn  fi-om  stock  or  backor¬ 
dered.  When  software  fails,  it  is  necessary  to  redesign  the  software  and  then  manufacture 
and  distribute  copies;  only  after  these  functions  are  done  can  a  replacement  program  be 
provided  to  correct  the  failure  condition.  Hence,  computer  program  resupply  can  rarely 
be  as  responsive  as  hardware  resupply.  Issues  of  software  hcensing,  con-figuration  man¬ 
agement,  and  software  reuse  must  be  addressed. 

7.2.5  Support  and  Test  Equipment 

Support  and  test  equipment  is  the  term  applied  to  all  equipment  (mobile  or  fixed)  required 
to  support  the  operation  and  maintenance  of  the  defense  system,  including  ground  han¬ 
dling  equipment,  tools,  metrology/calibration  equipment,  manual/automatic  test  equip¬ 
ment,  and  other  single-/multi-use  support  items.  Acquisition  logistics  efforts  should  strive 
to  reduce  or  eliminate  the  number  of  tools  and  support  equipment  required  to  maintain  the 
defense  system.  If  tools  and/or  support  equipment  are  shown  to  be  absolutely  needed, 
standardization  should  be  considered.  The  introduction  of  unique  types  of  Automatic  Test 
Systems  (ATS)  into  the  DoD  field,  depot,  and  manufacturing  operations  should  be  mini¬ 
mized.  The  use  of  commercial  testers  and  components  should  be  encouraged,  by  consid¬ 
ering  Automated  Test  Equipment  (ATE)  hardware  and  software  requirements  that  can  be 
met  by  using  DoD  ATS  families  or  commercial  testers  along  with  critical  architecture  ele¬ 
ments  and  interfaces. 

Ideally,  system-level  troubleshooting  techniques  for  a  modem,  software-intensive  system 
win  include  performance  monitoring/fault  isolation  capability  (on-line  maintenance  and  di¬ 
agnostic  programs)  with  some  foundation  in  software.  This  will  aid  the  user  in  initially 
recognizing  a  failure  and  distinguishing  (at  the  systems  level)  between  a  hardware  and 
software  failure.  An  integrated  hardware-software  support  facility  can  greatly  aid  in  sys¬ 
tem  supportability.  Generally,  hardware  failures  are  further  isolated  by  either  a  built-in 
test  (with  its  associated  software  in  more  modern  systems),  external  automatic  test  equip¬ 
ment  (also  with  its  software  programs),  or  manual  test  equipment  such  as  voltmeters  or 
oscilloscopes).  Software  failure  is  further  isolated  by  means  of  the  support  software.  This 
can  be  either  built  into  the  operational  software  (as  in  self-healing  software)  or  externally 
applied  in  conjunction  with  the  operational  software  (using  module  test  tools,  debugging 
routines,  or  off-line  diagnostic  routines). 

7.2.6  Technical  Data 


Technical  data  is  scientific  or  technical  information  (recorded  in  any  form  or  medium)  nec¬ 
essary  to  operate  and/or  maintain  the  defense  system.  Acquisition  logistics  efforts  should 
strive  to  optimize  the  quantity,  format,  and  interchangeability  of  technical  data.  Data  re¬ 
quirements  should  be  consistent  with  the  planned  support  concept  and  represent  the  mini¬ 
mum  essential  to  effectively  support  the  fielded  system.  Government  requirements  for 
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contractor-developed  support  data  should  be  coordinated  with  the  data  requirements  of 
other  program  functional  specialties  to  minimize  data  redundancies  and  inconsistencies. 
The  program  office  should  ensure  compatibility  with  existing  internal  government  infor¬ 
mation  processing  systems.  However,  maximum  use  should  be  made  of  available  con¬ 
tractor  data  systems  and  data  formats  when  they  can  readily  satisfy  program  needs. 

Demanding  unlimited  government  data  rights  or  delivering  truckloads  of  technical  publi¬ 
cations  does  not  always  solve  technical  data  problems.  Careful  selection  of  hardware  and 
software  documentation  approaches  and  techniques  is  essential.  The  quantity  of  data  pro¬ 
cured  and  its  associated  quality  must  also  be  considered.  Currency  and  accuracy  of  deliv¬ 
ered  data  are  also  important.  Managers  must  be  meticulous  in  selecting  the  items  of 
documentation  required  to  support  a  modem,  software-intensive  system. 

Language  is  also  an  important  consideration.  For  years,  English  has  been  the  common 
language  in  the  hardware  world;  however,  English  language  vocabulary  in  the  software 
world  has  not  yet  matured  into  a  standard  set  of  words  and  meanings.  The  available  num¬ 
ber  of  different  programming  Higher  Order  Languages  (HOL),  e.g.,  CMS-2,  JOVIAL, 
COBOL,  FORTRAN,  Ada,  ATLAS,  etc.,  creates  a  challenge  in  selection.  Necessity  for 
assuring  language  standardization  and  control  is  a  significant  software  supportability  con¬ 
sideration.  A  CALS  interface  between  the  contractor  and  the  government  activities  is 
needed  for  expeditious  technical  data  transfer. 

7.2.7  Training  and  Training  Support 

Training  and  training  support  includes  the  processes,  procedures,  curricula,  techniques, 
training  devices,  simulators,  and  other  equipment  necessary  to  train  civilian  and  active 
duty/reserve  duty  personnel  to  operate  and  support/maintain  the  defense  system.  This  in¬ 
cludes  individual  and  crew  training  (both  initial  training  and  follow-on  training);  new 
equipment  training;  and  initial,  formal,  and  on-the-job  training.  In  addition  to  the  defense 
system,  logistics  support  planning  normally  includes  acquisition,  installation,  operation, 
and  support  of  training  equipment/devices.  Acquisition  logistics  efforts  should  strive  to 
minimize  the  training  and  training  support  required  to  effectively  operate  and  support  the 
defense  system. 

Computer-aided  instruction  offers  considerable  economy  and  great  promise.  Self-paced 
instmction  is  also  proving  to  be  an  efficient  learning  tool  and  is  gaining  greater  acceptance 
among  the  Services  every  day.  Both  types  of  instmction,  however,  usually  require  IT  de¬ 
vices,  consisting  of  both  hardware  and  software,  which  must  be  supported.  Simulators 
and  trainers  that  simulate  the  operational  system  have  been  used  in  the  past  and  are  in¬ 
creasing  in  sophistication,  effectiveness,  and  affordability.  The  more  modem  of  these  de¬ 
vices  include  both  hardware  and  software.  Embedded  training  (trainers  that  utilize  the  op¬ 
erational  hardware  loaded  with  a  training  program  in  order  to  function  as  a  training  de¬ 
vice)  is  another  approach  offering  great  cost-effectiveness  for  the  future. 
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Operator  and  maintenance  training  for  software-intensive  systems  must  be  provided  in  a 
timely  manner  to  support  planned  introduction  rates  of  these  systems.  This  effort  must  in¬ 
clude  instruction  in  both  hardware  and  software,  depending  on  the  purpose  of  the  training 
and  operational  system  itself.  The  differences  between  hardware  maintenance  and  soft¬ 
ware  support  require  an  entirely  different  training  track  for  each  and  recognition  that  the 
software  logistician  must  be  a  skilled  computer  programmer. 

Before  training  begins,  an  overall  training  plan  is  usually  prepared,  including  instruction  in 
formal  schools,  informal  on-the-job  training,  and  required  adjustments  to  existing  training 
in  related  areas.  Instruction  in  system  operation,  organizational-level  maintenance,  inter¬ 
mediate-level  maintenance,  and  depot-level  maintenance  is  normally  provided.  Hardware 
and  software  are  addressed  at  each  level  to  the  degree  dictated  by  the  operational  and 
maintenance  concepts.  New  material  introducing  team  trainmg,  instructor  training,  and 
refresher  training  must  also  be  developed. 

Courses  of  instruction  also  require  planned  student  selection  criteria,  prerequisites,  course 
capacity,  lesson  plans,  scheduling,  and  course  materials.  Other  required  resources  may  in¬ 
clude  trainers,  simulators,  additional  systems  dedicated  to  training,  and  training  software 
development. 

7.2.8  Facilities 

Facilities  include  the  permanent,  semi-permanent,  or  temporary  real  property  assets  re¬ 
quired  to  operate  and  support  the  system.  The  facilities  analysis  includes  conducting 
studies  to  define  necessary  facilities  or  facility  improvements  and  determining  locations, 
space,  utilities,  environmental,  real  estate,  and  equipment  needs.  Acquisition  logistics  ef¬ 
forts  should  strive  to  minimize  or  eliminate  the  facilities  required  to  operate  and  support 
the  defense  system.  Where  facilities  are  demonstrated  to  be  absolutely  needed,  maximiz¬ 
ing  the  use  of  existing  facilities  should  be  considered. 

Hardware  maintenance  facilities  can  be  generally  broken  down  into  organizational,  inter¬ 
mediate,  depot-level,  or  other  special  levels  (such  as  four  or  five  levels  of  maintenance). 
Buildings,  special  power,  clean  rooms,  anechoic  chambers,  shielded  cages,  space  for  sup¬ 
port  and  test  equipment,  offices,  and  the  like,  faU  into  this  category.  Software  facilities 
can  be  generally  thought  of  in  terms  of  organizational  and  depot-level  maintenance  facili¬ 
ties  (programming  support  centers).  Buildings,  special  power,  special  equipment  cooling, 
equipment  spaces,  tape  library,  and  offices  are  in  this  category. 

The  locations  of  hardware  and  software  maintenance  facilities  bear  careful  consideration  in 
terms  of  cost,  responsiveness,  efficiency,  and  other  factors.  Co-location  of  both  facilities 
may  result  in  better  efficiency  and  responsiveness  but  must  be  balanced  with  the  econo¬ 
mies  inherent  in  depot  inter-servicing.  Existing  facilities  or  existing  facility  modifications 
must,  likewise,  be  carefully  evaluated  before  decision  to  construct  new  facilities. 
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The  equipment  required  to  develop  and  produce  hardware  (such  as  an  assembly  line)  has 
tended,  in  the  past,  to  be  different  from  the  equipment  required  to  maintain  hardware. 
Items  required  to  develop  and  produce  software  are  usually  identical  to  the  tools  required 
to  mflintain  software.  The  following  components  comprise  the  programming  support 
center: 


•  software  development  laboratory; 

•  hardware  integration  laboratory;  and 

•  a  test  system  (for  final  checkout). 

7.2.9  Packaging,  Handling,  Storage,  and  Transportation 

Packaging,  Handling,  Storage,  and  Transportation  (PHS&T)  includes  the  resources,  proc¬ 
esses,  procedures,  design  considerations,  and  methods  to  ensure  that  the  defense  system, 
equipment,  and  support  items  are  packaged/preserved,  handled,  stored,  and  transported 
properly.  The  related  analysis  includes  determination  of  environmental  considerations, 
preservation  requirement  for  short-  and  long-term  storage,  transportability  requirements, 
and  other  methods  to  ensure  elimination/minimization  of  damage  to  the  defense  system 
and  its  necessary  support  infrastructure.  Acquisition  logistics  efforts  should  strive  to 
minimize  or  eliminate  undue/unnecessary  packaging,  handling,  storage,  and  transportation 
requirements  for  the  operation  and  maintenance  of  the  defense  system. 

Containers,  forklift  trucks,  cargo  aircraft,  warehouses,  commercial  transport,  security, 
packing  materials,  paperwork,  transport  schedules,  preservation,  cargo  ships,  dock  work¬ 
ers,  pipelines,  and  a  host  of  similar  factors  characterize  PHST.  Key  emphasis  is  on  the 
avoid^ce  of  damage  or  deterioration  in  safe  and  timely  movement  and  storage  of  systems. 

PHST  is  generally  more  of  a  problem  for  hardware  than  software.  Hardware  is  usually 
large  and  bulky,  whereas  software  may  be  contained  in  a  single  reel  of  magnetic  tape. 
Hardware  damage  in  transport  or  handing  is  usually  repaired;  software  damage  is  usually 
attributable  to  the  media  conveying  the  software  program  or  to  alteration  of  the  state  of 
information  in  the  media  and  is  repaired  by  reissuing  or  duplication  the  program  using  new 
media. 

Extended  storage  can  pose  a  problem  for  volatile  conq)uter  memories  whose  contents  may 
be  lost  or  altered.  Hardware  can  be  expected  to  deteriorate  with  age.  Although  software 
does  not  wear  out,  its  media  does.  Software  also  tends  to  become  obsolete  very  quickly 
because  of  rapid  advances  in  the  state-of-the-art. 
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7.2.10  Computer  Resources  Support 

Proper,  comprehensive,  and  careful  attention  to  the  hardware  and  software  implications  of 
each  of  the  aforementioned  logistics  elements  and  support  infrastructure  should  reduce  or 
ehminate  the  need  to  separately  address  any  remaining  issues  regarding: 

•  facilities; 

•  hardware; 

•  software  (system  software  and  support  software); 

•  documentation; 

•  personnel;  or 

•  other  resources  necessary  to  operate  and  support  computer  systems  and  soft- 
ware-intensive  systems. 

Acquisition  logistics  efforts  should  strive  to  ensure  that  computer  resources  support  is  es¬ 
tablished  in  a  cost-effective  and  timely  manner  for  the  growing  number  of  software  inten¬ 
sive  defense  systems. 

The  optimum  maintenance  concept  cannot  be  selected  without  inclusion  of  both  hardware 
and  software  considerations.  Likewise,  tradeoffs  among  all  the  logistics  elements  must  in¬ 
clude  both  the  hardware  and  software  implications  within  each  logistics  element.  Table 
7B  lists  the  more  prominent  implications.  To  trade  off  the  hardware  implication  of  aU  lo¬ 
gistics  elements  against  the  software  implications  of  only  one  logistics  element  wdl  not  fa¬ 
cilitate  support  system  optimization  in  a  modem  software-intensive  system. 

It  is  virtually  impossible  to  design  a  modem,  military  system  without  a  computer  and  the 
software  accompanying  it.  This  poses  a  greater  challenge  for  the  future.  The  solution  lies 
in  superior  perspective  and  sound,  integrated  management  at  all  levels  of  both  government 
and  industry. 

7.2.11  Design  Interface 

Design  interface  will  remain  the  primary  area  of  the  integration  among  the  logistics  and 
systems/software  engineering  functions.  However,  the  interface  area  must  be  extended 
beyond  design  in  order  to  ensure  program  success.  A  smooth,  seamless  interface  between 
logistics  and  all  other  related  disciplines  (such  as  systems  and  software  engineering,  test 
and  evaluation,  manufacturing,  life-cycle  cost  and  financial  resources)  is  essential  to  over- 
all  program  success.  Use  of  Integrated  Product  Teams  (IPTs),  with  logistics  representa¬ 
tion,  is  the  preferred  method  to  achieve  this  result  during  aU  phases  of  the  defense  systems 
acquisition  management  process. 
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TABLE  7B 

HARDWARE  VERSUS  COMPUTER  RESOURCES  SUPPORT 


HARDWARE 

SOFTWARE 

THE 

MAINTENANCE 

PLAN 

3-LEVEL 

FAILED  PART  AND  PAPER 

REPAIR 

2-LEVEL 

PAPER  PROBLEM  DESCRIPTION  ONLY 
MODIFICATION 

MANPOWER 

AND  PERSONNEL 

AVERAGE  LOWER  SKILL  LEVELS 
RELATIVE  ADEQUACY  OF  NUMBERS 
RETENTION  RATES  -  AVERAGE 

AVERAGE  HIGHER  SKILL  LEVELS 
RELATIVE  SHORTAGE  OF  NUMBERS 
RETENTION  RATES  -  A  PROBLEM 

SUPPORT  AND 
TEST  EQUIPMENT 

SYSTEM  LEVEL  PERFORMANCE 
MONITORING/FAULT  ISOLATION 
BUILT-IN  TEST 

(EXTERNAL)  AUTOMATIC  TEST  EQUIPMENT 
TEST  EQUIPMENT 

ON-LINE  MAINTENANCE  AND 
DIAGNOSTIC  PROGRAMS 

BUILT-IN  TEST  SOFTWARE 
AUTOMATIC  TEST  EQUIPMENT  SOFTWARE 
SUPPORT  SOFTWARE 

TRAINING 

AND 

TRAINING 

SUPPORT 

SYSTEM  HARDWARE  OPERATION 
HARDWARE  MAINTENANCE  TRAINING 
COMPUTER-AIDED  INSTRUCTION 
TRAINER/SIMULATOR 

SYSTEM  SOFTWARE  OPERATION 
SOFTWARE  MAINTENANCE  TRAINING 
COMPUTER-AIDED  INSTRUCTION  SOFTWARE 
TRAINING  DEVICE  SOFTWARE 

SUPPLY 

SUPPORT 

PROVISION  AND  RESUPPLY  ALREADY 
DESIGNED  ITEMS 

RESUPPLY  HARDWARE 

USE  EXISTING  PARTS/MODULES/ 

END  ITEMS  TO  MAX  EXTENT  POSSIBLE 

MODIFY  THE  SOFl  V/.\RE 

AND  THEN  SUPPLY  IT 

RESUPPLY  TRANSFER  MEDIA 

USE  EXISTING  PROGRAMS/COMPUTER- 
PROGRAM  COMPONENTS  TO 
MAXIMUM  EXTENT  FEASIBLE 

TECHNICAL 

DATA 

ENGLISH  LANGUAGE 

HARDWARE  DOCUMENTA¬ 
TION  CONVENTIONS 

TECHNICAL  PUBLICATIONS 

HIGHER  ORDER  LANGUAGE 
SOFTWARE  DOCUMENTA¬ 
TION  CONVENTIONS 

PROGRAM  DOCUMENTATION 

PACKAGING, 
HANDLING, 
TRANSPORTATION 
AND  STORAGE 

AVOID  DAMAGE/DETERIORATION 

IN  SYSTEM  MOVEMENT  - 
REPAIR  IF  DAMAGED 

HARDWARE  WEAROUT 

CONVEY  PROGRAM  UPDATES 

TO  UNITS  -  REPLACE  WITH  ANOTHER 

COPY  IF  DAMAGED  OR  ALTERED 

SOFTWARE  DOES  NOT  WEAR  OUT  - 
ITS  MEDIA  DOES 

FACILITIES 

ORGANIZATIONAL, 
INTERMEDIATE,  AND 

DEPOT  MAINTENANCE  FACE.ITIES 

ORGANIZATIONAL  AND 

DEPOT  MAINTENANCE  FACILITIES 

PRODUCTION-LINE  AND  MAINTENANCE 
FACILITIES  DIFFERENT 

PRODUCTION-LINE  AND  MAINTENANCE 
FACILITIES  IDENTICAL 
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7.2.12  Other 


Additional  areas  that  may  be  considered  by  the  IPT  include;  Rebability,  Availability,  and 
Maintainability  (RAM);  Life-Cycle  Cost  (LCC);  Logistics  Support  Resource  Funding;  etc. 
These  additional  areas  are  inportant  functional  elements  of  program  success.  In  the  past, 
some  of  these  were  included  at  various  times  as  logistics  elements. 

7.2.13  Tailoring 

With  no  official  identification  or  definitions  of  the  logistics  elements  in  DoDD  5000. 1  or 
DoD  5000.2-R,  IPTs  are  free  to  “tailor”  the  logistics  elements  to  best  suit  the  specifics  of 
their  programs. 

7.2.14  Logistics  Elements  and  Associated  Software  Issues 

Table  7C  lists  the  logistics  elements  and  provides  associated  software  issues  under  each 
element.  The  major  issues  were  addressed  earlier  in  this  Chapter;  hence  the  list  is  some¬ 
what  redundant.  However,  these  issues  were  interspersed  with  hardware  considerations; 
and  other  issues  shown  in  the  Table  were  not  addressed.  The  table  is  intended  to  serve  as 
a  software  “checklist”  and  to  emphasize  software  considerations  rather  than  the  older, 
better-known  (or  longer- standing)  hardware  considerations. 
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TABLE  7C 

LOGISTICS  ELEMENTS  AND  ASSOCIATED  SOFTWARE  ISSUES 


MAINTENANCE  PLANNING 

Software  Maintenance  Concept 
Software  Life-Cycle  Support  Plan 
Pre-Planned  Product  Improvement 
Source,  Maintainability,  Recoverability  Coding 
Contractor  versus  In-house  Support 
Transition  Plan 

MANPOWER/PERSONNEL 

Contractor  versus  In-house 
Military  versus  Civilian 
Mix  versus  Enhanced  Profile 
Core  Software  Logisticians 
Skill  Mix 

SUPPLY  SUPPORT 

Communication  Transfer  Media 

Inventory  Management 

Configuration  Management 

Software  and  Firmware  Cataloging 

Software  Re-use 

Storage 

Security 

Licensing 

SUPPORT  EQUIPMENT 

Computer-Aided  Software  Engineering  (CASE)  Tools 

Integrated  Support  Facility 

Depot  versus  Field 

Simulation/Simulators 

Actual  Hardware 

TECHNICAL  DATA 

Specifications/Documentation 

CALS  Interface  for  Technical  Data  Transfer 

Regulation  Conflicts  (Tech  Order  Data) 

Failure  Reporting 
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TABLE  7C  (Continued) 

LOGISTICS  ELEMENTS  AND  ASSOCIATED  SOFTWARE  ISSUES 


TRAINING 

System  Operations 
Software  Logistics 
Simulators/Trainers 
Computer-Based  Training  Media 
Human  Factors 
Failure  Reporting 

COMPUTER  RESOURCES  SUPPORT 

Integrated  Support  Facilities 
Support  Environment 
Security  Partitioning 

Computer  Resources  Logistics  Support  Planning/Documentation 
Support  Software 

FACILITIES 

In-house  versus  Contractor 
Operational  Location  versus  Depot 
Foreign  Military  Sales  Support 
Security  &  TEMPEST  Space  Planning 
Communications 
Human  Factors 

Backup  and  Disaster  Recovery  Provisions 

DESIGN  INTERFACE 

Capacity  -  Memory/Throughput 

Reliability/Maintainability/Safety 

Support  Level:  Field  versus  Depot 

Support:  In-house  versus  Contractor 

Firmware  Interfaces 

Life-Cycle  Costing 

Commercial  Items 

Security 

Re-use 
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8 

SYSTEMS  ENGINEERING 
AND  SUPPORTABILITY  ANALYSES 


The  success  of  a  logistics  program  hinges  on  how  the  readiness  and 
supportability  characteristics  are  designed  into  the  system. 

Key  concept 


8.1  INTRODUCTION 

The  purpose  of  this  chapter  is  to  address  the  role  of  logistics  as  an  element  in  the  Systems 
Engineering  (SE)  process.  Only  selected  highlights  of  the  SE  process,  i.e.,  those  that 
clarify  the  linkage  between  logistics  and  SE,  are  presented  herein. 

The  SE  process  is  used  to  translate  operational  needs  and  requirements  into  a  system  so¬ 
lution  that  includes  the  design,  manufacturing,  test  and  evaluation,  and  support  processes 
and  products.  A  major  goal  of  SE  is  the  achievement  of  a  proper  balance  among  per¬ 
formance  (including  readiness  and  supportability),  risk,  cost,  and  schedule.  This  goal  is 
sought  by  employing  the  following  top-down  iterative  steps  that  define  the  SE  process: 
requirements  analysis,  functional  analysis  and  allocation,  design  synthesis  and  verification, 
and  system  analysis  and  control. 

The  readiness  and  supportability  characteristics  of  a  system  must  be  included  in  the  design 
in  during  the  early  phases,  i.e..  Concept  Exploration  (CE)  and  Program  Definition  and 
Risk  Reduction  (PDRR),  while  the  system  design  is  in  its  formative  stages  and  tradeoffs 
are  most  easily  accomplished.  Thereafter,  these  characteristics  must  be  reevaluated  con¬ 
tinually  through  the  life  of  the  program,  considering,  among  other  things,  the  opportunity 
for  technology  insertion  to  enhance  readiness  and  supportability.  The  optimal  way  to 
achieve  this  result  is  to  establish  a  rigorous  formal  relationship  at  the  onset  of  system  de¬ 
velopment  and  between  the  logistics  system  design  effort  and  the  SE  process.  Readiness 
and  supportability  characteristics  must  be  considered  in  performing  functional  and  tradeoff 
analyses,  and  the  SE  process  provides  the  framework  for  enabling  the  effective  acquisition 
of  a  supportable  system. 

System  maintainability  and  supportability  goals  are  best  achieved  by  addressing  support 
requirements  as  elements  of  the  SE  tradeoff  and  decision  criteria.  A  balanced  integration 
of  logistics  considerations  in  the  SE  process  achieves  the  following  objectives: 

•  produces  readiness  objectives  that  will  be  challenging  but  attainable. 


8-1 


•  identifies  realistic  reliability  and  maintainability  requirements  to  achieve  these 
objectives, 

•  identifies  support  and  manpower  drivers,  and 

•  assigns  appropriate  priority  to  logistics  element  requirements  in  system  design 
tradeoffs. 

Four  summary  points  are  worthy  of  mention  as  a  foundation  for  the  logistics/SE  linkage: 

The  SE  process  is  iterative  in  nature,  entailing  four  elements:  requirements  analysis;  func¬ 
tional  analysis/allocation;  synthesis;  and  overall,  systems  analysis  and  control.  Feedback 
loops  between  each  of  the  first  three  elements  are  an  essential  part  of  the  process.  Of 
these,  the  feedback  loop  between  the  synthesis  element  and  the  design  requirements  ele¬ 
ment  represents  the  verification  process,  involving  testing  and  evaluation,  audits,  and  de¬ 
sign  reviews  to  provide  appropriate  feedback  regarding  the  attainment  of  system  require¬ 
ments.  Figure  8-1  illustrates  the  iterative  nature  of  this  process. 


•  Further,  SE  is  applied  repetitively  within  each  phase  of  the  acquisition  process.  A 
progressive  change  in  the  central  focus  of  SE  takes  place  as  the  development  pro¬ 
gresses,  starting  with  system-level  considerations  in  the  early  phases,  subsequently 
overlaid  with  subsystem  considerations  (which  become  the  focus  in  the  mid¬ 
phases),  and  followed  later  by  conponent  considerations  as  the  design  matures. 
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•  There  are  many  “elements”  to  be  considered  in  the  SE  process.  Some,  like 
design  engineering,  come  readily  to  mind  when  SE  is  mentioned.  Others,  like 
environmental  compatibility,  electromagnetic  compatibility,  vulnerability,  and 
conunonality,  are  elements  that  must  be  considered  throughout  the  SE  proc¬ 
ess;  but  they  tend  to  require  more  SE  Integrated  Product  Team  (IPT)  effort  to 
keep  them  in  the  foreground  during  tradeoffs,  planning,  and  evaluation.  A 
term  has  been  coined  to  account  for  many  of  these  items  with  names  ending  in 
“ility”  -  the  “Dities.”  Figure  8-2  combines  the  many  “roots  and  limbs”  of  SE 
into  a  systemic  entity. 

•  Because  logistics  considerations  are  an  element  of  SE,  they  must  be  integrated 
into  the  SE  process  from  the  onset.  Supportability  and  readiness  analyses  are 
essential  in  each  stage  of  the  process.  A  word  of  caution  is  necessary,  how¬ 
ever,  regarding  the  relationship  between  the  design  engineer  and  the  logisti¬ 
cian.  At  times,  design  considerations  are  likely  to  be  in  conflict  with  the  sup- 
portability  and  maintainabiUty  concerns  of  the  logistician.  In  such  cases  trade 
studies  can  be  used  to  identify  the  proper  resolution  of  such  conflicts.  When 
conflicts  do  occur,  it  is  important  that  readiness  and  supportability  issues  be 
given  the  same  importance  as  program  schedule  and  performance.  To  say  that 
logistics  and  supportability  analyses  are  a  part  of  SE  does  not  imply  that  the 
logistics  voice  is  subservient  to  the  engineering  voice  on  the  integrated  team 
or  in  the  project  office.  Organizationally,  the  logistician  must  be  a  principal 
player  in  the  development  process. 

8.1.1  Design  Considerations 

Many  considerations  influence  system  design,  and  chief  among  them  are  the  following: 

•  cost; 

•  manufacturing/production; 

•  quality; 

•  open-system  design; 

•  logistics/supportabiUty; 

•  rehability,  maintainability; 

•  environment  and  safety; 

•  human  systems  integration;  and 

•  interoperability 
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Figure  8-2:  Systems  Engineering  and  the  "Ilities 


This  Chapter  will  concentrate  on  three  of  the  topics,  i.e.,  open  system  design,  support- 
ability,  and  rehability/maintainability.  These  topics  deserve  emphasis  because  of  their 
close  association  with  activities  of  the  Logistics  Manager  (LM)  and,  in  the  case  of  open 
system  design,  because  of  current  DoD  poUcy  emphasis. 

8,2  OPEN  SYSTEMS  DESIGN 

The  following  material  is  presented  at  the  onset  of  the  SE  Chapter  in  recognition  of  the 
importance  of  open  systems  architecture  in  reducing  system  life-cycle  cost.  The  system 
architecture  should  be  addressed  early  in  a  program,  as  part  of  the  SE  process,  to  maxi¬ 
mize  the  number  of  potential  solutions  and,  thereby,  help  reduce  program  cost.  By  de¬ 
veloping  the  architecture  early  in  a  program,  the  specific  technology  used  in  its  imple¬ 
mentation  can  then  be  chosen  as  late  as  possible.  The  following  material  has  been 
adapted  from  the  “Open  Systems  Joint  Task  Force”  section  of  the  DoD  Deskbook. 

8.2.1  Discussion 

The  open  system  approach  entails  a  plan  structured  to  facilitate  the  use  of  widely 
accepted  standard  products  from  multiple  suppliers.  In  instances  where  system  archi¬ 
tecture  is  defined  by  the  specifications  and  standards  used  in  the  private  sector,  DoD  can 
be  one  of  many  customers  and  leverage  the  benefits  of  the  commercial  marketplace.  The 
open  system  approach  can  have  a  profound  effect  on  the  life-cycle  cost  of  a  system  as 
diseussed  below. 

•  With  its  implementation,  program  managers  have  access  to  alternative  sources 
for  the  key  subsystems  and  components  to  construct  DoD  systems. 

•  DoD  investment  early  in  the  life  cycle  is  reduced,  since  at  least  some  of  the 
required  subsystems  or  components  are  likely  to  be  available. 

•  Produetion  sources  can  be  competitively  selected  from  multiple  competitors. 

•  The  system  design  flexibility,  inherent  in  the  open-system  approach,  and  the 
more  widespread  availability  of  conforming  commercial  products,  mitigates 
potential  problems  associated  with  a  diminishing  defense-dependent  manu¬ 
facturing  base. 

•  Standards-based  architecture  facilitates  upgrades  by  incremental  technology 
insertion,  rather  than  by  large-scale  system  redesign. 

The  open  system  approach  is  an  integrated  technical  and  business  strategy  that  defines 
key  interfaces  for  the  system  (or  piece  of  equipment)  being  developed.  Interfaces  gener¬ 
ally  are  best  defined  by  formal  consensus  (adopted  by  recognized  industry  standards 
bodies)  on  specifications  and  standards.  However,  eonunonly  accepted  specifications  and 
standards  (both  company  proprietary  and  nonproprietary)  are  also  acceptable  if  they  fa¬ 
cilitate  utihzation  of  multiple  suppliers.  The  use  of  de  facto  specifications  and  standards 
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takes  advantage  of  the  fact  that  firms,  particularly  those  in  the  commercial  arena,  fre¬ 
quently  develop  hardware,  software,  and  systems  standards  for  the  design  and  fabrication 
of  computing,  telecommunications,  display,  sensing,  and  signal  processing  systems. 
Whether  interfaces  are  described  by  consensus  or  de  facto  standards  the  benefits  only  ac¬ 
crue  if  products  from  multiple  sources  are  economically  possible.  Although  the  most 
conunon  emphasis  is  on  electronic  systems,  the  open  system  approach  is  widely  applica¬ 
ble,  from  fasteners  and  hght  bulbs  to  jet  engines. 

An  effective  open-system  architecture  will  rely  on  physical  modularity  and  functional 
partitioning  of  both  hardware  and  software.  Physical  modularity  and  functional  parti¬ 
tioning  should  be  aligned  to  facilitate  the  replacement  of  specific  subsystems  and  compo¬ 
nents  without  impacting  others.  The  subsystems  and  components  described  by  the  system 
design  should  be  consistent  with  the  system  repairable  level.  Subsystems  and  compo¬ 
nents  below  the  repairable  level  will  normally  not  be  under  government  configuration 
control.  Therefore,  repairs  below  the  repairable  level,  if  required,  will  be  by  the  supplier. 
If  the  hardware  and  software  is  effectively  partitioned,  processing  hardware  can  be  re¬ 
placed  with  new  technology  without  modifying  application  software.  In  addition,  appli¬ 
cation  software  can  be  modified  without  necessitating  hardware  changes. 

Open-system  interfaces  must  be  managed  more  rigorously  than  in  previous  practice.  An 
interface  specification  or  standard  is  inherently  a  performance  standard,  is  used  as  such 
by  industry,  and  must  be  recognized  as  such  in  DoD.  System  partitions  must  not  violate 
the  interface,  unilaterally  extend  it,  or  define  it  so  that  it  is  no  longer  comphant  with  the 
standard.  At  the  start  of  production,  the  open-system  requirements  are  pubhshed,  thus 
identifying  the  market  opportunities  for  supphers. 

8. 2. 1.1  Military  Requirements.  The  open-system  approach  facilitates  the  use  of  lower 
cost,  high-performance  subsystems  and  components,  mostly  built  to  commercial  specifi¬ 
cations  and  standards  within  the  overall  system.  The  open-system  approach  does  not  im¬ 
ply  that  only  consumer-grade  products  should  be  used.  However,  some  commercial  envi¬ 
ronments  are  as  demanding  as  military  environments,  and  commercial  products  that 
function  in  these  environments  will  also  function  in  the  miUtary  environment.  In  any 
case,  all  open-system  designs  still  must  meet  military  requirements. 

8.2. 1.2  Legacy  Systems.  The  application  of  the  open-system  approach  to  legacy  systems 
is  less  obvious  but  still  beneficial.  Legacy  systems  usually  have  size,  space,  power, 
cooling,  and  shape  factor  constraints.  For  these  systems,  the  open  system  approach  can 
provide  Form-Fit-Function  Interface  (F3I)  solutions  within  existing  packaging,  power, 
and  environmental  constraints.  In  such  cases  the  open-system  solution  frequently  re¬ 
quires  less  system  resources  by  using  newer,  more  efficient  technologies.  The  open-sys¬ 
tem  approach  is  similar  to  FBI  except  that  the  open-system  approach  emphasizes  choos¬ 
ing  interfaces  that  are  broadly  accepted  in  the  marketplace  to  allow  for  as  many  supphers 
as  possible  over  the  long  term. 

8.2. 1.3  A  Smart  Business  Practice.  The  open-system  approach  is  a  new  way  of  doing 
business  and  an  important  part  of  acquisition  reform.  More  importantly,  the  open-system 
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approach  is  a  smart  way  to  do  business.  Hard  pressed  to  maintain  the  superiority  of  U.S. 
military  systems  within  severe  budget  constraints,  DoD  program  managers  need  the 
flexibihty  of  open  system  to  leverage  the  creativity  and  competitive  pressures  of  the 
commercial  marketplace.  Program  managers  should  ask  this  question  of  any  proposed 
design  solution:  “What  provisions  have  been  made  to  ensure  that  the  widest  range  of 
suppliers  will  have  the  opportunity  to  offer  their  products  throughout  the  program  life  cy¬ 
cle?” 


8.2.2  Example  Applications 

Examples  of  open-system  apphcations  are  such  initiatives  as  the  rapid  prototyping  of  ap¬ 
plication-specific  signal  processors  (RASSP)  at  the  Defense  Advanced  Research  Projects 
Agency  (DARPA)  and  the  F- 16  Falcon  modular.  In  addition,  the  F-22  aircraft  (formerly 
the  JAST  program)  is  coordinating  its  technology  investments  with  industry  and  acade¬ 
mia  and  other  Defense  Department  science  and  technology  organizations.  The  F-22  is 
evolving  and  demonstrating  an  open-system  architecture,  consistent  with  the  new  acqui¬ 
sition  pohcies  and  practices.  Another  example  is  the  Information  Technology  Standards 
Integrated  Bulletin  Board  System  (ITSI  BBS). 

8.2.3  Tools 

DoD  Technical  Architecture  Framework  for  Information  Management  (TAFIM), 
Version  2.0,  30  June  1994,  is  a  proven  tool  for  information  management.  See  the 
information  provided  below. 

8.2.4  POC/Reference 

•  Office  of  the  Under  Secretary  of  Defense  for  Acquisition  and  Technology 
(USD(A«&T))/DTSE&E,  tel:  703-695-2300. 

•  Service  Acquisition  Executives. 

•  Director,  OSJTF,  tel:  703-578-6160/6568  or 
Home  Page  —  http://www.aca.osd.mil/ositf/ 

•  DoD  5000.2-R,  paragraph  4.3.4. 

•  USD(A&T)  memo  of  10  July  1996,  Subj:  Open  Systems  Acquisition  of  Weap¬ 
ons  Systems  (Deskbook)  and  resulting  Service  Acquisition  Executive’s  plans  for 
open-system  approach  for  acquired  systems. 

•  DoD  Technical  Architecture  Framework  for  Information  Management 
(TAFIM),  Version  2.0, 30  June  1994,  tel:  703-696-1750  or  Deskbook. 

•  rrSI  BBS  Modernization  Project  (webmaster@itsi.disa.mil),  tel:  703-735-8338 
or  DSN  653-8338 
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83  SUPPQRTABILITY  ANALYSES 


Supportability  factors  must  be  considered  in  an  organized  manner  throughout  design 
and/or  planning  actions  for  the  system  being  acquired  and  for  each  apphcable  logistics 
support  element  as  well.  To  reiterate,  logistics  and  supportabiUty  analyses  must  be  inte¬ 
grated  with  and  be  a  part  of  the  SE  process.  In  the  past  this  frequently  was  not  the  case. 
SupportabiUty  analyses  were  often  accompUshed  in  a  nonintegrated  fashion,  producing 
reports  and  recommendations  with  limited  impact  on  design.  Only  by  including  logistics 
considerations  in  the  design  tradeoffs  within  the  SE  process  and  throughout  the  develop¬ 
ment  cycle  can  the  program  achieve  its  operational  goals  at  the  lowest  Uf e-cycle  cost. 

SupportabiUty  analyses,  when  conducted  within  the  SE  process,  form  the  basis  for  deci¬ 
sions  on  the  scope  and  level  of  logistics  support;  and,  of  equal  importance,  they  lead  to 
performance  requirements  in  the  system  specification  and  thus  influence  design  consid¬ 
erations.  The  analyses,  like  the  SE  process,  are  ongoing  throughout  the  development  cy¬ 
cle  in  iterative  fashion.  The  initial  analyses  should  focus  on  the  relationships  of  the 
evolving  operational  and  readiness  requirements,  planned  support  structures,  and  com¬ 
parisons  with  existing  force  structure  and  support  posture.  SupportabiUty  analyses  can 
include  any  number  of  tools,  practices,  or  techniques,  many  of  which  are  described  in 
Section  8.5  below.  The  foUowing  items  are  examples  of  the  types  of  analyses  that  might 
be  performed  to  provide  appropriate  inputs  to  an  integrated  Operational  Requirements 
Document  (ORD),  which  reflects  an  operational  and  support  concept  that  the  user  finds 
acceptable. 

83.1  Logistics  Strategy 

The  logistics  strategy  identifies  the  logistics  management  structure  and  authority;  what 
supportabiUty  analyses  and  verification  activities  are  planned;  who  will  be  responsible  for 
each  activity;  and  how  the  results  of  each  activity  will  be  used.  There  is  no  standard  for¬ 
mat  for  the  plan.  It  should  be  tailored  for  each  program  and  should  be  part  of  the  Systems 
Engineering  Management  Plan  (SEMP). 

83.2  Use  Study 

The  use  study  defines  the  intended  use  of  the  system/component  and  the  operational  and 
support  environments  of  that  system/component.  Quantitative  support  factors,  such  as 
operational  availabiUty  (Ao),  transportation  modes/times,  allowable  maintenance  periods, 
and  environmental  requirements  (including  hazardous  materials,  hazardous  wastes,  and 
other  pollutants),  are  identified.  These  data  are  then  incorporated  into  the  ORD  as  appro¬ 
priate.  The  use  study  should  include  consideration  of  the  following  items: 

•  planned  deployment  scenarios, 

•  transportabiUty  requirements, 

•  mission  frequency  and  duration. 
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•  human  factors  (system  complexities  and  the  supportability  implications), 

•  anticipated  service  life,  and 

•  standardization  and  interoperability. 

8  Analysis  of  Comparative  Systems 

This  analysis  strives  to:  1)  define  a  sound  analytical  foundation  for  projecting  a  new  sys¬ 
tem  design  and  related  supportability  features,  2)  identify  aspects  that  need  improvements 
over  those  in  existing  systems,  and  3)  identify  those  features  that  will  likely  drive  cost, 
support,  and  readiness  of  the  new  system. 

83.4  Evaluation  of  Technological  Approaches/Opportunities 

The  purpose  of  this  analysis  is  to  identify  technological  advancements  and  state-of-the-art 
design  approaches  that  offer  opportunities  to  achieve  new  system  support  improvements. 
Use  of  available  technological  approaches  is  emphasized  to  improve  upon  projected 
safety,  cost,  support,  and  readiness  values;  to  reduce  a  new  system’s  environmental  im¬ 
pact;  and  to  resolve  quahtative  support  problems. 

83.5  Postproduction  Support 

The  Postproduction  supportabihty  analysis  should  identify  items  that  are  single/dual 
source  or  those  for  which  the  government  cannot  obtain  data  rights.  The  related  plan  of 
action  to  alleviate  projected  problem  areas  should  consider  organic  support  capabiUty, 
production  line  buy-out,  or  contractor  logistics  support  agreements. 

8.4  SYSTEMS  ANALYSIS  AND  CONTROL 


Six  major  activities  and  tools  are  used  in  systems  analysis  and  control.  They  are: 

•  tradeoff  studies, 

•  configuration  management, 

•  data  management, 

•  risk  management, 

•  metrics,  and 

•  technical  reviews. 

Only  the  first  two  activities  will  be  discussed  in  the  Chapter. 
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8.5  TRADEOFF  STUDIES 


Desirable  and  practical  tradeoffs  among  requirements,  technical  objectives,  design,  pro¬ 
gram  schedule,  functional  and  performance  requirements,  and  life-cycle  costs  must  be 
identified  and  conducted  throughout  the  development  process. 

8.5.1  Requirements  Analysis  Tradeoff  Studies 

The  performing  activity  needs  to  conduct  requirements  analysis  tradeoff  studies  to  estab¬ 
lish  alternative  performance  and  functional  requirements  to  both  resolve  conflicts  with 
and  satisfy  user  requirements.  Of  primary  importance  in  establishing  support  alternatives 
is  the  following  guidance  in  DoD  5000.2-R,  which  gives  precedence  to  contractor- 
provided  logistics  support  in  many  situations: 

”It  is  DoD  pohcy  to  retain  hmited  organic  core  depot  maintenance  capa¬ 
bility  to  meet  essential  wartime  surge  demands,  promote  competition,  and 
sustain  institutional  expertise.  Support  concepts  for  new  and  modified 
systems  shall  maximize  the  use  of  contractor-provided,  long-term,  total 
life-cycle  logistics  support  that  combines  depot-level  maintenance  along 
with  wholesale  and  selected  retail  materiel  management  functions.  Life- 
cycle  costs  and  use  of  existing  capabilities,  particularly  while  the  system  is 
in  production,  shall  play  a  key  role  in  the  overall  selection  process.  Other 
than  stated  above,  and  with  an  appropriate  waiver,  DoD  organizations  may 
be  used  as  substitutes  for  contractor-provided  logistics  support,  such  as 
when  contractors  are  unwitting  to  perform  support,  or  where  there  is  a 
clear,  well-documented  cost  advantage.  The  PM  shall  provide  for  long-temi 
access  to  data  required  for  competitive  sourcing  of  systems  support.  The 
waiver  to  use  DoD  organizations  must  be  approved  by  the  MDA.” 

When  considering  alternative  systems  or  alternative  support  concepts,  the  fol¬ 
lowing  items  are  representative  of  appropriate  comparison  criteria: 

•  life-cycle  cost  comparisons, 

•  diagnostic  characteristics  (e.g.,  Built-in-Test  (BIT)), 

•  energy  characteristics, 

•  battle  damage  repair  characteristics, 

•  transportability  characteristics,  and 

•  facilities  requirements. 

8.5. 1.1  Supportabititv  Factors.  DoD  5()(X).2-R  states  that:  “Supportabitity  factors  are  in¬ 
tegral  elements  of  program  performance  specifications.  However,  support  requirements 
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are  not  to  be  stated  as  distinct  logistics  elements,  but  instead  as  performance  requirements 
that  relate  to  a  system’s  operational  effectiveness,  operational  suitability,  and  life-cycle 
cost  reduction.”  The  following  items  are  examples  of  supportability  issues  upon  which 
specific  objectives  can  be  based: 

•  operations  and  maintenance  personnel  and  staff-hour  constraints, 

•  personnel  skill  level  constraints, 

•  life-cycle  and  Operations  and  Support  (O&S)  cost  constraints, 

•  target  percentages  of  system  failures  correctable  at  each  maintenance  level, 

•  mean  down  time  in  the  operational  environment, 

•  tum-around  time  in  the  operational  environment, 

•  standardization  and  interoperability  requirements, 

•  built-in-fault  isolation  capability,  and 

•  transportability  requirements  (identification  of  conveyances  on  which  the  system 
and  its  components  are  transportable). 

8.6  CONFIGURATION  MANAGEMENT 

Configuration  Management  (CM)  is  a  defined  process  applying  sound  business  practices  to 
manage  the  configuration  of  defense  materiel  items,  their  defining  technical  data,  and  support¬ 
ing  digital  data  files.  It  involves  interaction  among  government  and  contractor  program  func¬ 
tions  such  as  SE,  design  engineering,  logistics,  test,  contracting,  and  manufacturing.  It  is  best 
accomplished  in  an  IPT  environment  consistent  with  the  program  infrastructure  and  concept  of 
operations.  There  are  four  distinct  functions  to  configuration  management:  configuration  identi¬ 
fication,  configuration  control,  configuration  status  accounting,  and  configuration  audits. 

8.6.1  Configuration  Identification 

Configuration  identification  is  the  identification  of  documents  comprising  the  configura¬ 
tion  baselines  for  the  system  and  lower-level  items  (including  logistics  support  elements) 
and  identifiers  for  those  items  and  documents.  When  thus  identified,  an  item  is  known  as 
a  configuration  item  (Cl). 
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8.6.2  Configuration  Control 

The  configuration  control  process  manages  the  current  configuration  baseline  that  results 
from  the  configuration  identification  process.  The  types  and  levels  of  documentation 
subject  to  government  configuration  control  authority  are  defined  in  pertinent  contracts. 
At  an  agreed  to  point  in  the  development  process,  the  government  generally  accepts  con¬ 
figuration  control  responsibilities  and  establishes  a  configuration  control  board  (CCB). 
Requests  for  engineering  changes  are  received  from  government  technical,  operational, 
and  contract  functions;  and  requests  for  Engineering  Change  Proposals  (ECPs)  are  sent  to 
the  contractors.  Additionally,  ECPs  and  requests  for  deviations  are  received  from  con¬ 
tractors.  After  disciplined  assessment  of  impact,  cost,  and  risk  by  the  CCB,  approval  of 
beneficial  changes  and  the  necessary  authorization  and  direction  for  change  implementa¬ 
tion  by  contractors  are  provided  to  contractors  through  the  contractual  process  and  to  af¬ 
fected  government  activities  through  appropriate  channels. 

Under  current  acquisition  reform  initiatives,  numerous  system  support  functions  will  be 
carried  out  by  industry  under  contract.  In  some  cases  total  contractor  configuration  man¬ 
agement,  including  configmation  control,  is  a  distinct  possibihty.  In  most  cases,  how¬ 
ever,  the  government  will  retain  the  configuration  control  function. 

A  CCB  is  typically  staffed  with  the  IPT  responsible  for  the  item,  which  means  the  LM 
will  be  a  part  of  the  team.  Government  CCBs  typically  review  proposed  changes  that 
impact  the  item’s  performance  requirements  only.  Conversely,  the  contractor’s  change 
control  authority  typically  evaluates  changes  that  impact  the  design  solution  to  the  item’s 
performance  requirements  and  do  not  impact  the  performance  requirements. 

8.6.3  Configuration  Status  Accounting 

The  heart  of  Configuration  Status  Accounting  (CS  A)  is  a  transaction  database  fed  by  the  trans¬ 
actions  that  take  place  under  other  CM  processes.  It  provides  visibility  into  status  and  configu¬ 
ration  information  concerning  the  product  and  its  documentation.  In  essence,  it  provides  a  track 
of  configuration  documentation  changes,  i.e.,  the  configuration  history,  and  documents  the  con¬ 
figuration  of  CIs.  With  the  onset  of  the  DoD  initiative  to  gain  total  asset  visibility,  the  CSA  da¬ 
tabase  win  likely  be  interconnected  with  the  network  that  provides  total  asset  visibility. 

8.6.4  Configuration  Verification  and  Audit 

Configuration  verification  and  audit  uses  each  of  the  following  data  types  at  appropriate 
points  in  the  development  cycle: 

•  schedule  information  from  status  accounting, 

•  configuration  documentation  for  configuration  identification, 

•  the  results  of  product  testing. 
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•  the  physical  hardware  or  software  product  or  its  representation, 

•  manufacturing  instructions,  and 

•  the  software  engineering  environment. 

These  data  are  used  to  verify  that  the  product’s  performance  requirements  have  been 
achieved  by  the  product  design,  and  the  product  design  has  been  accurately  documented 
in  the  configuration  documentation.  The  process  also  includes  verifying  the  incorpora¬ 
tion  of  approved  engineering  changes. 

Configuration  verification  should  be  an  imbedded  function  of  the  contractor’s  process  for 
creating  and  modifying  the  product.  Process  vaUdation  by  the  government  in  heu  of 
physical  inspection  may  be  appropriate.  Successful  completion  of  verification  and  audit 
activities  results  in  a  verified  product  and  documentation  set  that  may  be  confidently  con¬ 
sidered  a  product  baseline,  as  well  as  a  validated  process  that  will  maintain  the  continuing 
consistency  of  product  to  documentation.  MlL-HDBK-61  contains  guidelines  for  con¬ 
duction  configuration  audits. 

8.7  SUPPORT  ABILITY  ANALYSES 

The  contractor  necessarily  performs  many  supportabihty  analyses;  and,  thus,  it  is  impor¬ 
tant  that  the  requirement  for  analysis  reports  be  clearly  addressed  in  contractual  terms. 
With  the  advent  of  acquisition  reform,  a  performance  specification  (MIL-PRF-49506, 
Logistics  Management  Information)  has  been  developed  and  issued  to  assist  in  this  re¬ 
gard.  It  addresses  in  broad  terms  each  of  the  following  example  analyses,  which  roughly 
parallel  the  logistics  elements  discussed  in  Chapter  7:  maintenance  planning;  repair 
analysis;  support  and  test  equipment;  manpower,  personnel,  and  training;  facihties;  pack¬ 
aging,  handling,  storage,  and  transportation;  and  postproduction  support.  Further  ampU- 
fication  is  provided  in  the  performance  specification.  However,  these  topics  are  pre¬ 
sented  only  as  examples  of  useful  support  information  that  DoD  managers  may  want  to 
require  from  a  contractor  and  are  not  all-inclusive  or  exclusive. 

A  worksheet  format  for  supportabihty  analysis  summaries  is  provided  in  the  specifica¬ 
tion.  Figure  8-3  is  a  representation  of  that  format.  Note  that  it  has  a  space  to  be  filled  in 
by  the  DoD  manager  to  indicate  what  data  are  required  in  a  specified  analysis  report  to  be 
included  in  the  LMI  specification.  Another  space  is  provided  to  identify  those  data  ele¬ 
ments  not  included  in  the  LMI  specification.  A  separate  worksheet  would  be  required  for 
each  analysis  addressed  in  the  contract.  In  the  following  section,  several  types  of  sup¬ 
portabihty  analyses  are  discussed. 
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MIL-PRF-49506 
APPENDIX  A 


Page _ of 


SUMMARY  TITLE: 

SPECIFIC  INSTRUCTIONS: 

DATA  IN  LMI  SPECIFICATION  (Please  provide  the  data  product  title.): 

DATA  NOT  IN  LMI  SPECIFICATION  (Please  provide  the  data  product  title,  its  definition,  and  its 
format.): 


SUMMARY  LAYOUT  (if  applicable):  Government  Provided  Contractor  Provided  'll 


Figure  8-3:  Worksheet  1,  Supportability  Analysis  Summaries 
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8.7.1  Reliability,  Maintainability,  and  Availability  (R,M&A)  Analyses 

The  paragraphs  that  follow  in  this  section  discuss  analyses  that  contribute  to  R,M&A. 
Supportability  analyses  play  a  key  role  in  planning,  designing,  and  fielding  a  reliable  and 
maintainable  system.  In  organizing  this  Guide,  Chapter  10  has  been  devoted  to  the  topic 
of  reliability  and  maintainability.  However,  the  sections  that  foUow  are  more  appropri¬ 
ately  placed  in  this  Chapter  deahng  with  SE. 

8.7. 1.1  Definitions. 

•  Reliability  is  the  probability  that  an  item  will  perform  its  intended  functions 
for  a  specified  period  under  stated  conditions.  Reliability  can  be  further  bro¬ 
ken  down  into  mission  reliability  and  logistics  reliability: 

—  Mission  reliability  is  the  probability  that  a  system  will  perform  mission- 
essential  functions  for  a  period  of  time  under  the  conditions  stated  in  the 
mission  profile.  Measures  of  mission  reliability  include  only  those  inci¬ 
dents  affecting  mission  accomplishment. 

—  Logistics  reliability  is  the  probability  that  no  corrective  maintenance  or 
unscheduled  supply  demand  wiU  occur  following  the  completion  of  a 
specified  mission  profile. 

•  Maintainability  is  the  probability  that  an  item  will  conform  to  specified  con¬ 
ditions  within  a  given  period  when  corrective  or  preventive  action  is  per¬ 
formed  in  accordance  with  prescribed  procedures  and  resources. 

•  Availability  is  a  measure  of  the  degree  to  which  an  item  is  in  the  operable  state.  It  is 
ready  to  commit  at  tiie  start  of  a  mission,  even  when  die  mission  is  called  for  at  an 
unknown  (random)  point  in  time.  The  efficacy  of  the  supply  support  and  mainte¬ 
nance  systems  as  well  as  the  Reliability  and  Maintainability  (R&M)  characteristics 
of  the  item  influences  the  factor  in  question. 

Contracting  for  Reliability  and  Maintainability.  An  important  technique  for  achieving  the 
R&M  goals  is  to  provide  meaningful  contract  incentives  in  the  early  stages  of  the  program. 
From  program  inception  through  the  EMD  phase  and  into  the  early  stages  of  production, 
R&M  plans  and  goals  should  always  be  a  source  selection  evaluation  factor;  and  the  contracts 
resulting  from  the  source  selection  should  have  incentive  clauses  related  to  the  levels  of 
R&M  achieved  and  verified.  The  use  of  contract  warranties  is  often  cost-effective  in  the  pro¬ 
duction  and  later  stages  of  the  program.  However,  the  operational  scenario  must  be  evaluated 
to  determine  if  warranty  conditions  are  practical.  Warranties  sometimes  impose  unrealistic 
handling,  shipping,  and  data  collection  demands  on  the  operational  user  and  field  mainte¬ 
nance  organization,  making  it  difficult  to  enforce  the  warranty  provisions. 
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8.7.2  Maintenance  Planning  Analysis 

The  contractor  generally  performs  the  maintenance  planning  analysis.  The  resulting  summa¬ 
ries  provide  maintenance  planning  information  to  the  government;  they  may  be  used  to  de¬ 
velop  initial  fielding  plans  for  the  end  items’  support  structure.  The  information  contained 
therein  is  associated  with  the  repairable  items  to  the  level  of  detail  specified  on  contract  Pre¬ 
ventive  and  corrective  maintenance  actions  should  be  identified  along  with  required  spares 
and  support  equipment.  Additional  supporting  information,  such  as  elapsed  time  of  mainte¬ 
nance  actions,  task  firequencies,  failure  rate,  mean  times  to  repair,  and  man-hour  allocations 
by  maintenance  action  and  level,  should  be  required  for  each  item. 

8.73  Repair  Analysis 

Emanating  from  the  contractor’s  maintenance  repair  analysis,  these  summaries  provide 
the  government  with  conclusions  and  recommendations.  The  contract  may  ask  for  actions 
and  recommendations  for  influencing  the  system  design  and  a  listing  of  which  items 
should  be  repaired  and  discarded.  For  each  item  being  repaired,  they  may  also  identify 
the  level  of  maintenance  to  be  performed  and  the  associated  costs.  Further,  for  the  sys¬ 
tem  support  structure,  they  may  identify  the  operational  readiness  achieved  and  the 
placement  and  allocation  of  spares,  support  equipment,  and  personnel. 

The  summaries  should  also  provide  an  explanation  of  the  input  data  used  and  their 
source,  the  operational  scenario  modeled,  assumptions,  constraints,  maintenance  alterna¬ 
tives  considered,  the  analytical  method  and  model  used  to  perform  the  economic  evalua¬ 
tions,  and  a  discussion  of  the  sensitivity  evaluations  performed  in  reaching  the  summary 
conclusions  and  recommendations. 

8.7.4  Support  and  Test  Equipment 

These  summaries  provide  the  government  with  data  necessary  to  register,  or  verify  the 
registry  of,  the  support  or  test  equipment  in  the  government’s  inventory.  They  may  pro¬ 
vide  details  of  the  Test,  Measurement,  and  Diagnostic  Equipment  (TMDE)  calibration 
procedures,  technical  parameters,  and  any  piece  of  support  equipment  needed. 

8.7.5  Supply  Support 

These  summaries  provide  the  Government  with  information  that  may  be  used  to  deter¬ 
mine  initial  requirements  and  cataloging  of  support  items  to  be  procured  through  the  pro¬ 
visioning  process.  The  following  data  items  may  be  included:  identification  of  the  sys¬ 
tem  breakdown,  maintenance  coding,  maintenance  replacement  factors,  overhaul  rates, 
roU-up  quantities,  design  change  information,  associated  technical  manuals,  long  lead 
items,  bulk  items,  tools,  test  equipment,  etc.  These  summaries  may  also  allow  for  review 
of  Provisioning  List  Item  Sequence  Number  (PLISN)  assignment  or  cross-referencing 
PLISNs  with  reference  numbers. 
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8.7.6  Manpower,  Personnel,  and  Training  Analysis 

These  summaries  provide  information  to  the  Government  so  that  it  can  establish  training 
plans  and  ensure  manpower  and  personnel  constraints  are  met.  The  analysis  report 
should  identify  the  items’  corrective  and  preventive  maintenance  tasks,  operations  tasks, 
manpower  estimates  for  each  task  by  maintenance  level,  personnel  skills  required  to  per¬ 
form  the  maintenance  tasks,  and  any  training  required  to  allow  these  tasks  to  be  per¬ 
formed. 

8.7.7  Facilities  Analysis 

These  summaries  identify  the  facilities  required  to  maintain,  operate,  train,  and  test  an 
item.  The  facilities  may  be  organizational,  intermediate,  or  depot  maintenance  training, 
mobile,  and  test  facilities.  The  summary  information  contained  within  shall  help  plan  for 
any  modification  to  an  existing  facility  or  development  of  a  new  facihty. 

8.7.8  Packaging,  Handling,  Storage,  and  Transportation  Analysis 

These  summaries  identify  the  packaging,  handling,  storage,  and  transportation  require¬ 
ments.  They  also  provide  information  relevant  to  the  development  of  a  transportability 
analysis  report. 

8.7.9  Postproduction  Supportability  Analysis 

The  purpose  of  these  analyses  is  to  review  life-cycle  support  requirements  of  the  new 
system  and  associated  items  prior  to  closing  production  hnes.  These  reviews  ensure  the 
appropriate  support  for  the  system  over  its  remaining  life.  They  identify  the  potential 
“weak  links”  in  the  future  support  posture,  together  with  alternative  solutions  to  alleviate 
those  anticipated  support  difficulties. 

8.7.10  Redundancy  Analysis 

In  cases  where  the  design  concept  involves  redundancy  to  meet  reliability  requirements, 
the  possible  result  is  improved  mission  reliability  gained.  However,  this  gain  may  be  at 
the  cost  of  reduced  logistics  reliability  and  increased  support  costs.  Attempts  should  be 
made  to  improve  single-unit  reliability  whenever  possible  to  preclude  the  need  for  redun¬ 
dancy.  As  a  general  rule,  the  designer  should  use  redundancy  in  mechanical  systems  as  a 
last  option.  However,  electronic  circuitry  is  a  different  matter  due  to  size,  weight  and 
complexity  considerations.  Circuits  boards  can  be  designed  with  spare  components  in¬ 
stalled  and  a  logic  to  switch  from  a  failed  component  to  a  backup  spare  (even  multiple 
spares  in  succession)  to  maintain  mission  readiness.  In  this  instance,  the  redundancy  can 
be  very  cost  effective,  allowing  a  potentially  complex  circuit  board  to  remain  in  opera¬ 
tional  use  without  being  compromised  by  a  single  point  of  failure. 
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8.7.11  Failure  Modes  and  Effects  Criticality  Analysis  (FMECA) 

FMECA  is  an  analysis  procedure  whereby  each  potential  failure  mode  in  a  system  is 
analyzed  to  determine  its  results  or  effects  on  the  entire  system.  The  analysis  then  classi¬ 
fies  each  potential  failure  mode  according  to  its  severity.  It  further  attempts  to  identify 
all  single  points  of  failure,  i.e.,  those  points  where  failure  of  the  component  can  cause 
failure  of  the  entire  system.  The  results  of  the  FMECA  must  then  be  utiUzed  in  the  de¬ 
sign  process  to  reduce  the  probabihty  of  failures  through  design  modification.  Single 
points  of  failure  must  be  eliminated.  The  benefits  of  a  FMECA  include  less  initial  re¬ 
design;  reduced  scope  of  the  Test,  Analyze,  Fix,  and  Test  (TAFT)  effort;  enhanced  prob¬ 
ability  of  meeting  system  cost  and  schedule  goals;  and  improved  customer  satisfaction.  The 
Society  of  Automotive  Engineers  is  in  the  process  of  writing  a  commercial  standard  cov¬ 
ering  FMECA  guidelines. 

For  more  details,  read  the  Reliability  Toolbook:  Commercial  Practices  Edition,  pub- 
hshed  by  the  RehabiUty  Analysis  Center,  ITT  Research  Institute,  Rome,  NY. 

8.7.12  Reliability  Centered  Maintenance  Analysis 

Reliability  Centered  Maintenance  analysis  uses  information  from  FMECA  to  identify 
items  most  critical  to  system  availabihty.  The  purpose  of  the  analysis  is  to  develop  a 
scheduled  maintenance  program  with  the  goal  of  increasing  system  availabihty  by  identi¬ 
fying  failures  or  potential  failures  before  they  degrade  system  effectiveness.  The  analysis 
uses  a  decision  tree  as  a  guide  for  complete  analysis  of  each  significant  item.  While 
equipment  is  in  operation,  preventive  maintenance  tasks  are  identified  and  scheduled  on  a 
routine,  periodic  basis  to  prevent  failures  and,  thus,  keep  the  equipment  running.  Preven¬ 
tive  maintenance  tasks  fall  into  two  subcategories:  scheduled  inspection  and  scheduled 
removal. 

For  more  details,  read  the  Reliability  Toolbook:  Commercial  Practices  Edition,  pubhshed 
by  the  Rehabihty  Analysis  Center,  ITT  Research  Institute,  Rome,  NY. 

8.7.13  Test,  Analyze,  Fix  and  Test 

TAFT  is  a  disciphned  process  for  systematically  detecting  and  eliminating  design  weak¬ 
nesses  while  simulating  the  operational  environment.  TAFT  should  start  with  the  first 
article  available  and  continue  until  requirements  are  achieved.  The  process  is  a  closed 
loop  in  nature;  all  detected  failures  are  recorded  and  analyzed,  a  redesign  effort  is  under¬ 
taken  to  ehminate  the  cause  of  failure,  testing  is  resumed,  and  the  redesign  is  verified. 
Based  on  system  requirements  and  the  operating  environment,  the  TAFT  plan  is  normally 
developed  by  the  contractor. 
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8.7.14  Failure  Reporting,  Analysis,  and  Corrective  Action  System  (FRACAS) 

The  FRACAS  is  an  adjunct  to  TAFT,  in  which  all  failures  and  faults  (not  just  those  that 
occur  in  the  operational  environment  testing)  of  both  hardware  and  software  are  formally 
reported.  Analyses  are  performed  to  determine  the  causes  of  failure,  and  positive  correc¬ 
tive  actions  are  taken. 

For  more  detail,  read  the  Reliability  Toolbook:  Commercial  Practices  Edition,  published 
by  the  Reliability  Analysis  Center,  Hr  Research  Institute,  Rome,  NY. 

8.8  SERVICE-LIFE  EXTENSION  PROGRAMS 

A  significant  number  of  systems  and/or  subsystems  have  life-limiting  characteristics,  e.g., 
met^  fatigue  (aircraft  structures),  corrosion,  or  mechanical  wear.  Such  systems  are  nor¬ 
mally  designed  and  tested  for  a  specified  service  life,  but  frequently  operational  require¬ 
ments  demand  an  extension  of  the  service  life  beyond  the  originally  planned  date.  As  plans 
are  laid  for  extending  the  service  life  of  the  system  or  subsystem,  the  program  office  should 
consider  the  formation  of  an  EPT  to  consider  all  aspects  and  impacts  of  the  extension.  All  of 
the  logistics  elements  must  be  analyzed  for  many  of  them,  such  as  supply  support,  mainte¬ 
nance,  training,  and  support  equipment,  are  apt  to  be  affected  by  the  extension. 

8.9  FLEXIBLE  SUSTAINMENT 

Flexible  Sustainment  (FS)  refers  to  “spares”  or  “parts.”  It  includes  what  “item  managers” 
do  as  well  as  activities  of  system  PMs.  It  can  also  be  defined  as  the: 

•  use  of  performance-based  specifications  including  the 

—  use  of  Form-Fit-Function  and  Interface  (F3I)  specifications  and  the 

—  use  of  nongovernment  standards; 

•  development  of  innovative,  cost-effective  hfe-cycle  solutions; 

•  logical,  decision-point-driven  process;  and 

•  control  of  ownership  cost  by  systematically  improving  reliability. 

For  further  information  on  flexible  sustainment,  refer  to  Chapter  26. 

8.10  PROCUREMENT  OF  TRAINING  AND  TRAINERS 

The  Federal  Acquisition  Streamlining  Act  of  1994,  the  Federal  Acquisition  Reform  Act 
of  1996,  and  DoDD  5000.1  and  DoD  5000.2-R  will  enable  significant  changes  to  DoD’s 
procurement  of  training  and  trainers  as  well  as  other  logistics  elements.  Best  business 
practices,  tempered  by  risk  and  threat  assessments,  must  be  used  to  determine  where 
outsourcing,  privatization,  and  competition  can  improve  the  performance  of  the  training 
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mission.  As  more  commercial  items  enter  the  inventory,  the  program  manager  and  his 
team  must  continue  to  utilize  acquisition  reforms,  privatization,  and  outsourcing  of  ap¬ 
propriate  training  and  logistics  elements. 

The  procurement  of  commercial  items  as  elements  of  the  system  adds  a  new  dimension  to 
the  determination  of  training  sources.  The  developers  of  commercial  items  are  likely  to 
have  spawned  one  or  more  commercial  training  sources,  which  may  prove  appropriate  in 
meeting  the  DoD  requirement.  In  a  similar  vein,  each  acquisition  program  should  exam¬ 
ine  opportunities  for  joint  training  with  other  DoD  components  or  allied  forces  to  achieve 
training  goals  at  reduced  cost. 

8.10.1  Examples/Tools 

The  recommended  way  to  develop  the  performance  specifications,  and  hence  to  identify 
needed  training  requirements,  is  through  the  use  of  a  training  IPT.  The  members  of  the 
IPT  must  ensure  that  they  identify  the  Logistics  Management  Information  (LMI)  needed 
to  determine  and  develop  the  system  operational  and  maintenance  training  requirements. 
The  LMI,  in  turn,  must  identify  what  training  is  needed  to  operate  and  maintain  the  sys¬ 
tem  and  what  training  sources  are  available.  These  elements  include  processes,  proce¬ 
dures,  techniques,  training  devices,  and  equipment  used  to  train  civilian  and  active  duty 
and  reserve  military  personnel  to  operate  and  support  the  system.  The  types  of  training 
should  include  individual  and  crew  training  (both  initial  and  continuation)  relative  to  new 
equipment  and  initial,  formal,  and  on-the-job  training.  These  LMI  requirements  must  be 
identified  early  in  the  acquisition  process  to  ensure  timely  development  of  a  training 
budget  that  will  satisfy  system  requirements. 

8.10.2  POC/Reference 

OUSD(A&T)/DTSE&E/DDSE/SESO 
Phone:  (703)681-4538 
Email;  desidegj  @  acq.osd.mil 
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9 

LOGISTICS  PLANNING 


P^:  Proper  prior  planning  prevents  pitifully  poor  performance. 

Sage  advice 


9.1  BACKGROUND 


Logistics  (or  supportability)  planning  is  undertaken  to  provide  a  plan  for  the  means  to 
support  the  fielded  system.  No  format  is  specified;  in  fact,  DoD  5000.2-R  states  that. 

“Program  plans  belong  to  the  PM  and  are  to  be  used  by  the  PM  to  man¬ 
age  program  execution  throughout  the  life  cycle  of  the  program.  Pro¬ 
gram  plans  are  a  description  of  the  detailed  activities  necessary  to  carry 
out  the  strategies  addressed  above.  The  PM,  in  coordination  with  the 
PEG,  determines  the  type  and  number  of  program  plans.  Program  plans, 
excluding  the  TEMP,  are  not  required  in  support  of  milestone  decisions  ^ 
and  shall  not  be  used  as  milestone  documentation  or  as  periodic  reports.” 

One  of  the  major  themes  of  DoD  5000.2-R  is  tailoring,  “because  one  size  does  not  fit  aU.” 
Common  sense  and  sound  business  practice  will  minimize  the  time  it  takes  to  satisfy  an 
identified  need.  Nevertheless,  the  prudent  Program  Manager  (PM)  will  develop  a  detailed 
logistics  plan  for  the  program,  either  as  a  separate  entity  or  as  a  subset  of  another  program 
document.  Typically,  the  plan  will  include  the  elements  of  the  logistics  program  and  Aeir 
relationship  with  overall  program  management;  and  it  will  ensure  coordination  of  logistics 
issues  among  aU  members  of  the  govemment/contractor  Integrated  Product  Teams  (IPTs). 
Logistics  planning  provides  guidance  and  direction  to  the  logistics  effort.  The  prepara¬ 
tion,  coordination,  use,  and  revision  of  logistics-related  plans  are  major  and  signhicant 
tasks  of  the  Logistics  Manager  (LM).  For  a  list  and  description  of  the  ten  logistics  ele¬ 
ments,  see  Chapter  7. 


Another  important  point  made  in  Section  2.6  of  DoD  5000.2  R  is  that. 

“. . .  supportability  factors  are  integral  elements  of  the  program  perform¬ 
ance  specifications.  However,  support  requirements  are  not  to  be  stated 
as  distinct  logistics  elements,  but  instead  as  performance  requirements 
that  relate  to  a  system’s  operational  effectiveness,  operational  suitability, 
and  life-cycle  cost.” 
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9.2  INTERATED  PRODUCT  TEA^^  gPT^ 


The  IPT  advises  and  assists  the  LM  with  planning,  coordinating,  and  monitoring  of  sched¬ 
ules  and  contractor  performance.  In  the  planning  effort,  the  team’s  support  includes: 

•  preparing  Request  for  Proposal  (RFP); 

•  developing  logistics  source  selection  criteria; 

•  developing  the  logistics  interface  of  management  plans; 

•  ensuring  the  accuracy  and  timeliness  of  government  inputs;  and 

•  evaluating  contractor  compliance  with  applicable  requirements,  regulations,  per¬ 
formance  and  detail  specifications,  standards,  and  guidelines. 

IPT  meetings  are  often  scheduled  in  conjunction  with  key  program  events.  Their  fre¬ 
quency  depends  on  the  intensity  of  planning  activity. 

9.3  KEY  SUPPORT  PLANS/PLANNING 


Key  planning  elements  include  an  overall  support  plan,  representing  top-level  logistics 
planning;  a  combined  or  separate  postproduction  support  plan;  and  a  combined  or  separate 
fielding/deployment  plan.  Figure  9-1  shows  typical  considerations  for  support  planning 

9.3.1  The  Top-Level  Support  Plan 

Although  the  Program  Manager  may  tailor  the  program  documentation,  development  of  a 
support  plan  is  strongly  recommended.  Such  a  plan  can  act  as  the  principal  logistics 
document  for  an  acquisition  program  and  serve  as  a  source  document  for  summary  infor¬ 
mation  in  other  documents,  such  as  the  Test  and  Evaluation  Master  Plan  (TEMPj.  The 
support  plan  should  reflect  the  set  of  support  requirements  documented  in  the  Mission 
Needs  Statement  (MNS)  and  the  Operational  Requirements  Document  (ORD);  and,  there¬ 
fore,  these  requirement-oriented  documents  are  a  logical  starting  point  in  the  preparation 
of  a  support  plan.  From  that  point,  the  considerations  listed  in  Figure  9-1  could  be  used  as 
the  outline  for  the  plan.  The  purpose  of  the  support  plan  is  to: 

•  provide  a  complete  plan  for  support  of  the  deployed  system,  addressing  and  in¬ 
cluding  each  support/logistics  element; 

•  provide  details  of  the  logistics  support  program  and  its  relationship  with  overall 
program  management; 
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SUPPORT  PLANNING 

Typical  Considerations 

•  General 

•  System  Description 

•  PM  Organization  and  Responsibiiities 

•  Appiicable  Documentation 

•  Goals  and  Strategy 

>  Operation  and  Organization  Concept 

•  System  Readiness  Objectives 

•  Logistics  Acquisition  Strategy 

•  Supportabiiity  Analysis  Scope  and  Tasks 

•  Supportabiiity  T&E  Concepts/Issues 

•  Logistic  Elements 

•  Maintenance  Plan;  Manpower;  Training;  PHS&T;  Support  Equipment; 
Suppiy  Support;  Tech  Data;  Facilities;  Cmptr  Res  Spt;  Design  interface 

•  Support  Funds 

•  Deployment,  Postfielding  Assessment  &  Postproduction 

•  Logistics  Miiestone  Schedule 

•  Logistics  Comparison  to  Program  Milestones 

•  Logistics  Elements  (Any  GFE  and  associated  S/E) 

•  Assignments,  Responsibilities  and  Events 


Figure  9-1  Typical  Considerations  in  Support  Planning 


•  state  the  acquisition  logistics  strategy; 

•  document  the  logistics  decisions  on  the  program; 

•  provide  necessary  information  on  logistics  aspects  necessary  for  sound  decisions  on 
further  development/production  of  the  basic  system; 

•  identify  further  logistics  effects/activities  needed;  and 

•  provide  the  basis  for  preparation  of  logistics  sections  of  the  procurement  pack¬ 
age,  e.g.,  Statement  of  Work,  Specification  and  Source  Selection,  and  Evaluation 
Criteria. 

The  support  plan  describes  the  overall  logistics  program,  encompassing  requirements, 
tasks,  and  milestones.  The  plan  is  tailored  to  the  specific  needs  of  each  program  and  will 
address  the  total  system,  including  the  end  item,  training  devices,  and  support  equipment. 
It  becomes  the  implementation  plan  for  aU  participating  activities  and  is  treated  as  an  inte¬ 
gral  part  of  the  total  program  planning  process.  Effective  implementation  of  the  plan  is  a 
major  management  challenge  because  of  the  numerous  logistics  support  interfaces. 
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9.3. 1.1  Time  Phasing.  The  Government  Program  Office  normally  prepares,  coordinates, 
and  starts  initial  logistics  planning  and  documentation  in  concert  with  the  system  user  and 
the  contractor  during  the  Concept  Exploration  (CE)  phase.  In  addition  to  plans  for  sup¬ 
port  of  the  fielded  system,  it  provides  the  basis  for  other  government  and  contractor  plan¬ 
ning  during  this  phase  and  for  logistics  planning  in  follow-on  phases.  It  should  include 
specific  tasks  to  be  accomplished  during  the  Program  Definition  and  Risk  Reduction 
(PDRR)  phase,  identify  responsible  Service  agencies  and  activities,  and  establish  the 
schedule  for  task  completion.  The  CE  should  also  project  requirements,  tasks,  and  mile¬ 
stones  for  future  acquisition  phases. 

During  PDRR  and  following  phases,  the  LM  may  obtain  contractor  assistance  to  review 
and  update  the  supportability  planning/plan.  The  plan  will  become  progressively  more 
detailed  as  the  program  design  activity  progresses.  It  is  normally  updated  when: 

•  new  program  direction  is  received; 

•  milestone  decision  reviews  are  approaching;  and  when 

•  major  system  configuration  changes  take  place. 

9.3. 1.2  Format.  Again,  no  standard  format  exists;  but  supportability  plans  typically  in¬ 
clude:  (1)  a  system  description  including  existing  equipment  and  associated  support 
equipment;  (2)  program  management  organization  and  responsibilities,  associated  Serv¬ 
ices,  agencies,  and  working  groups/Pits;  and  (3)  applicable  documents  involving  require¬ 
ments,  guidance,  and  evaluation  criteria.  Figure  9-1  on  the  preceding  page  represents  a 
recommended  outline  for  the  support  plan. 

9.3. 1.3  Concepts,  Goals,  and  Strategy.  The  supportability  plan  typically  covers  the  fol¬ 
lowing  topics,  which  are  tailored  as  appropriate  to  the  system  being  developed: 

•  operational  and  organizational  concept  involving  mission  requirements,  opera¬ 
tional  environment,  and  other  required  parameters; 

•  maintenance  concept,  to  later  be  enlarged  into  a  maintenance  plan  for  support  of 
the  fielded  system; 

•  system  readiness  objectives  for  both  peacetime  and  wartime  situations; 

•  logistics  acquisition  strategy  involving  contractual  approaches  and  incentives  as¬ 
sociated  with  Life-Cycle  Cost  (LCC),  Reliability  and  Maintainability  (R&M),  and 
supportability  goals; 

•  supportability  analyses  strategy,  which,  because  of  its  importance,  may  be  pro¬ 
vided  as  a  separate  document  that  describes  in  detail  the  supportability  analyses 
activities  and  the  results  expected; 
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•  supportability  test  and  evaluation  concepts  involving  identification  of  specific  test 
issues  related  to  overall  objectives  and  to  each  support  element; 

•  the  objectives,  concepts,  tradeoff  factors,  goals,  thresholds,  special  requirements, 
responsibilities,  and  validation  and  verification  requirements  for  each  support 
element.  Additionally,  the  manner  in  which  the  elements  of  logistics  are  progres¬ 
sively  specified,  designed,  tested  and/or  acquired,  and  then  integrated  with  the 
other  elements; 

•  support  resource  funds  involving  logistics-related  life-cycle  funding  requirements 
(funded  and  unfunded),  which  are  identified  by  element,  program  function,  and 
appropriation  category; 

•  postdeployment  assessments  which  involve  plans  that  analyze  and  assess  field 
data  feedback  related  to  materiel  support  and  support  system  performance;  and 

•  the  support  plan  addressing  assessment  methodology,  identifying  milestones  and 
responsibilities,  and  describing  the  strategies  for  improvements. 

9.3. 1.4  Milestone  Schedules.  The  support  plan  typically  provides  system  program  sched¬ 
ule  charts  showing  the  interrelationships  among  logistics  tasks  and  events  and  overall  pro¬ 
gram  milestones.  These  charts  focus  on  such  elements  as  management,  training,  testing, 
maintenance,  and  supply  support;  and  they  identify  assignments,  responsibilities,  and 
events.  The  milestone  schedules  are  the  baselines  for  planning  in  the  materiel  acquisition 
process,  therefore; 

•  System  program  schedule  charts,  used  by  program  management  should  depict  the 
most  essential  support  program  milestones.  The  milestones  relate  critical  support 
capabihties  to  overall  program  success. 

•  Milestone  data  should  include  the  nature  and  timing  of  activities  of  all  supporting 
contractor  and  government  organizations. 

•  Milestone  schedule  charts  should  include  a  system  program  schedule  and  a  sum¬ 
mary  logistics  program  schedule.  The  program  and  logistics  schedules  highlight 
the  relationships  between  key  events  on  the  two  charts. 

•  Individual  support  element  program  plans  should  include  a  program  schedule 
showing  key  program  milestone  achievements  for  that  particular  element. 

•  The  integrated  network  schedules  should  show  dependency  relationsliips  between  lo¬ 
gistics  elements.  Some  of  the  features  and  benefits  of  the  integrated  network  are: 
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—  computer-generated  critical  path  methodology  (such  as  the  Program 
Evaluation  Review  Techmque  (PERT)  and  Contractor  Performance  Meas¬ 
urement  (CPM))  to  define  critical  paths  and  slack  times; 

—  clear  visualization  for  management  of  interfaces; 

—  integration  with  the  program  management  information  system  (MIS);  and 

illustration  of  the  relationship  between  supportabUity  analyses  results  and 
the  various  logistics  elements,  to  facilitate  the  identification  of  support 
equipment,  acquisition  events,  procurement  lead  times,  etc. 

9.3.2  Postproduction  Support  Planning 

The  acquisition  strategy  for  AC  AT  I  and  lA  programs  must  address  postproduction  sup¬ 
port  (Section  3.3,  DoD  50()0.2-R),  and  sound  business  practice  would  extend  this  re¬ 
quirement  to  most  other  programs.  Highlights  regarding  postproduction  support  planning 
can  normally  be  extracted  fi'om  the  support  plan,  or,  the  postproduction  support  plan  may 
be  an  integral  part  of,  or  appendix  to,  the  support  plan.  A  postproduction  support  plan 
must  deal  with  the  challenging  need  to  sustain  effective  operations  and  readiness  after 
contractor  delivery  of  the  last  production  system.  Chapter  27  provides  a  more  complete 
discussion  of  postproduction  support. 

9.3.3  Deployment  Planning 

The  LM  can  also  prepare  a  plan  that  outlines  the  schedules,  procedures,  and  actions  necessary 
to  successfully  deploy  a  new  materiel  system.  Such  plans  are  given  different  names  in  difi'erent 
Service  organizations,  e.g.,  deployment  plan,  fleet  introduction  plan,  materiel  fielding  plan,  and 
site  activation  plan.  Much  of  this  planning  data  may  be  contained  in  the  support  plan.  Chapter 
25  provides  a  more  conplete  discussion  of  deployment  planning. 

9.3.4  Preplanned  Product  Improvement  (P^I) 

Preplanned  product  improvement  is  a  systematic  and  orderly  acquisition  strategy.  Begin¬ 
ning  at  the  early  phases  of  system  development  and  planning,  it  facilitates  evolutionary, 
cost-efiective  upgrading  of  a  system  throughout  the  life  cycle  and  enhances  readiness, 
availability,  and  capability.  The  purpose  of  P^I  is  to  develop  and  field  a  new  system  using 
known  technology,  while  formally  planning  for  the  phased  introduction  of  state-of-the-art 
improvements  to  that  system. 

9.4  TOOLS 

The  Logistics  Planning  and  Requirements  System  (LOGPARS)  is  a  personal  computer-based 
expert  system,  which  leads  an  ILS  manager  through  the  thought  process  necessary  to  plan  and 
execute  an  ILS  program.  It  helps  the  user  develop  acquisition  strategy  and  identify  ILS  con- 
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straints.  LOGPARS  incorporates  the  required  policy,  lessons  learned,  and  expert's  experience 
to  produce  critical  ILS  program  documentation.  The  systematic,  user-friendly  approach  LOG- 
PARS  offers  ensures  that  all  considerations  are  addressed,  encourages  compliance  with  existing 
policy,  and  eliminates  potential  for  contracting  redundant  information.  The  program  is  avail¬ 
able  on  line  at: 


http://www.logpars.army.mil/alc/logpars/logpars.htm 


9.5  SUMMARY 


There  are  several  keys  to  a  successful  logistics  program.  The  principal  ones  arc: 

•  recognition  that  logistics  is  involved  in  all  program  planning,  beginning  before 
program  initiation  (Milestone  0)  when  the  initial  Mission  Needs  Statement 
(MNS)  is  prepared; 

•  close  adherence  to  the  ORD  as  the  baseline  for  support  planning.  Chapter  5  of 
this  Guide  contains  a  section  on  the  ORD,  which  amplifies  on  this  point; 

•  effective  use  of  the  IPT  in  the  planning  process; 

•  preparation  of  a  support  plan,  with  the  characteristics  outlined  in  paragraph  9.3.1 
above,  and  tailored  to  the  system  being  acquired;  and 

•  implementation  of  the  plan  as  a  current  and  integral  part  of  the  overall  program. 
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10 

RELIABILITY,  AVAILABILITY,  AND 

maintainability' 


Reliability  and  Maintainability  are  Force  Ejfectiveness  Multipliers. 

Key  concept 


10.1  INTRODUCTION 

Reliable  systems  result  in  increased  combat  capability  while  requiring  fewer  spare  parts  and 
personnel.  Maintainable  systems  require  fewer  people  and  specialized  skills;  it  also  reduces 
maintenance  times.  These  reductions  result  in  lower  ownership  costs.  The  advantages  go  be¬ 
yond  the  system  itself.  Large,  conplex  combat  support  structures  are  vulnerable  to  attack. 
Reliable  systems  mean  reduced  dependence  on  airlift  and  pre-positioning.  This  chapter  will 
discuss  policies,  definitions,  requirements,  processes,  and  techniques.  The  contents  are  in¬ 
tended  to  give  the  reader  an  understanding  of  these  policies  and  procedures,  which  are  used  for 
design  of  developmental  systems  and  procurement  of  commercial  items. 


10.2  reliability,  availability,  and  maintainability  (RAM) 

POLICY  fPOD  5000.2-R) 

RAM  issues  should  be  addressed  early  in  the  acquisition  cycle  to  meet  operational  re¬ 
quirements  and  to  reduce  life-cycle  costs.  These  RAM  issues  should  be  stated  in  quantifi¬ 
able  operational  terms  that  are  measurable  during  testing.  Derive  fi'om  this  what  you  need 
to  support  system  readiness  objectives. 

•  Reliability  requirements  address  both  mission  reliability  and  logistics  reliability. 

•  Availability  requirements  address  readiness  of  the  system. 

•  Maintainability  requirements  address  servicing,  preventive,  and  corrective  main¬ 
tenance. 

The  PM  plans  and  executes  the  designing,  manufacturing,  and  testing  activities  that  dem¬ 
onstrate  the  system’s  performance  prior  to  production(s)  and  reflect  a  mature  design. 


'  Sections  10.1  through  10.5.4  are  based  on  the  contents  of  a  DSMC  Teaching  Note  prepared  by  Professor 
Mark  Fantasia,  Logistics  Management  Department,  March  1997.  The  Teaching  Note,  in  turn,  is  a  com¬ 
pilation  of  hundreds  of  pages  from  different  sources. 
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10.3  RELIABILITY.  AVAILABILITY.  AND  MAINTAINABILITY  OVERVIEW 


10.3.1  The  purposes  of  the  DoD  RAM  (DoD  5000.2-R)  are  to; 

•  increase  combat  capability/effectiveness  through: 

—  “user”  or  operator  measures  by  system  utilization,  operational  readi- 
ness/availabUity,  and  mission  success,  and 

—  mission  reliability  definition;  and 

•  reduce  life-cycle  ownership  costs  through: 

—  maintenance  manning,  and 

—  logistics  support. 

Commonly  Asked  Questions: 

What  is  Reliability  and  Maintainability  (R&M)?  Why  is  it  important? 

How  do  we  quantify  R&M  and  its  effects? 

How  much  R&M  is  needed,  and  what  can  we  expect? 

How  do  we  design  R&M  into  hardware  and  software? 

How  do  manufacturing  processes  affect  R&M? 

How  do  you  know  how  much  R&M  has  been  achieved? 

How  do  you  assess  fielded  systems? 

How  do  you  plan  and  manage  an  R&M  program? 

How  do  you  account  for  differences  in  fielded  R&M  versus  demonstrated  R&M? 

10.3.2  RAM  DeBnitions 

10.3.2. 1  Reliability.  Reliability  is  the  probability  that  an  item  will  perform  its  intended 
function  for  a  specified  interval  under  stated  conditions.  Simply  stated,  it  is  how  long  the 
system  can  work.  Mean  Time  Between  Failure  (MTBF)  is  eommonly  used  to  define  the 
total  functioning  life  of  a  population  of  an  item  during  a  specific  measurement  interval  di¬ 
vided  by  the  failures  during  that  interval.  The  failure  rate  (Greek  letter  lambda)  is  defined 
as  the  number  of  item  failures  of  per  measure  of  unit  life.  Sometimes  people  in  the  pro¬ 
gram  office  erroneously  use  MTBF  and  failure  rate  interchangeably. 

•  Failure  rate  can  be  calculated  as  follows: 

Failure  rate  =  1/MTBF  (failures  over  time) 

(Failure  rates  of  components  in  series  are  additive) 


•  Characteristics  of  failure: 

-  Types  of  failure  include: 

•  stress/strength  (bar  in  tension), 

•  damage/endurance  (corrosion/wear/fatigue). 
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•  challenge/response  (emergency  brake/SAV  program),  and 

•  tolerance/requirement  (copier  machine/measuring  instrument). 

-  Probability  of  success  (confidence  interval;  confidence  level) 

-  Prediction  (subject  to  much  disagreement) 

10.3.2.2  Mission  Reliability.  Mission  reliability  is  the  probability  that  a  system  will  per¬ 
form  mission-essential  functions  for  a  period  of  time  under  the  conditions  stated  in  the 
mission  profile.  Measures  of  mission  reliability  include  only  those  incidents  affecting  mis¬ 
sion  accomplishment. 

10.3.2.3  Logistics  Reliability.  Logistics  reliability  is  the  probability  that  no  corrective 
maintenance  or  unscheduled  supply  demand  will  occur  following  the  completion  of  a  spe¬ 
cific  mission  profile. 

10.3.2.4  Maintainability.  Maintainability  is  the  probability  that  if  prescribed  procedures 
and  resources  are  used,  an  item  will  be  retained  in,  or  restored  to,  a  specific  condition 
within  a  given  period.  It  is  the  inherent  characteristic  of  a  finished  design  that  determines 
the  amount  of  maintenance  required  to  retain  or  restore  the  system  into  a  specified  condi¬ 
tion.  Corrective  maintenance  can  be  measured  by  Mean  Time  to  Repair  (MTTR);  or, 
stated  in  more  simple  terms,  how  quickly  and  easily  the  system  can  be  fixed.  Also,  Mean 
Maintenance  Time  (MMT)  not  only  includes  corrective  maintenance  but  also  accounts  for 
preventive  maintenance. 

10.3.2.5  Availabditv.  Availability  is  based  on  the  question,  “Is  the  equipment  available  in  a 
v/orking  condition  when  it  is  needed?’  Availability  is  defined  as  the  probability  that  an  item  is 
in  an  operable  and  commitable  state  at  the  start  of  a  mission  when  the  mission  is  called  for  at  a 
random  point  in  time.  The  user  is  most  concerned  about  this  parameter.  This  reflects  the 
readiness  of  the  system.  There  are  a  number  of  definitions  of  availability,  and  it  is  important  to 
understand  the  basic  ones.  All  are  based  on  this  standard  mathematical  relationship,  with  dif¬ 
fering  definitions  of  the  terms  “Up  Time;”  “Down  Time;”  and  ‘Total  Time”: 

Availability  =  A  =  Up  Time  =  Up  Time _ 

Total  Time  Up  Time  +  Down  Time 

One  measure  in  particular.  Operational  Availability  (Ao),  covers  all  time  segments  the 
equipment  is  intended  to  be  operational.  As  seen  by  the  following  equation,  operational 
availability  is  based  on  a  mathematical  relationship  among  three  characteristics:  reliabihty, 
maintainability,  and  the  effectiveness  of  the  logistics  support  system.  Reliability  is  meas¬ 
ured  as  the  mean  operating  time  plus  mean  standby  time  in  an  operational  condition  (rep¬ 
resented  by  Mean  Time  Between  Maintenance  (MTBM)).  Maintainability  includes  the 
mean  maintenance  time  for  both  corrective  and  preventive  actions  (represented  by  Mean 
Maintenance  Time  (MMT)).  Logistics  support  effectiveness  is  the  combination  of  the  lo¬ 
gistics  delay  time  plus  any  administrative  delays  (represented  by  Mean  Logistics  Down 
Time  (MLDT)).  The  Mean  Time  Between  Maintenance  (MTBM)  is  based  on  all  mainte- 
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nance  actions,  whether  corrective  or  preventative  in  nature.  (See  the  Maintainability  Sec¬ 
tion  at  10.5.) 


Ao=  _ MTBM _ 

MTBM  +  MMT  +  MLDT 

Note:  There  are  a  number  of  program  support  contracts  that  require  the  contractor  to 
meet  an  Ao  requirement.  You  can  see  that  the  contractor  would  want  to  control  the  sup¬ 
port  structure  or  have  it  precisely  defined  before  signing  up  for  Ao. 

Another  measure,  Inherent  Availability  (Ai),  is  a  measure  of  the  system  availability  with 
respect  only  to  operating  time  and  corrective  maintenance.  Under  these  idealized  condi¬ 
tions,  the  time  involved  in  preventive  maintenance;  the  delay  times  associated  with  all 
types  of  maintenance  actions;  and  administrative  delays  are  ignored.  Because  only  un¬ 
scheduled  maintenance  actions  are  considered  in  this  definition,  the  mean  operating  time  is 
defined  as  the  Mean  Time  Between  Failure  (MTBF). 

Ai  =  MTBF 

MTBF  +  MTTR 

Inherent  availability  is  useful  in  determining  basic  system  operational  characteristics  under 
conditions  which  might  include  testing  in  a  contractor’s  facility  or  other  controlled  test 
environment.  Likewise,  inherent  availability  becomes  a  useful  term  to  describe  combined 
reliability  and  maintainability  characteristics.  Inherent  availability  is  also  used  to  define 
one  characteristic  in  terms  of  the  other  during  early  conceptual  phases  of  a  program  when, 
generally,  these  terms  cannot  be  defined  individually.  Since  this  definition  of  availability  is 
easily  measured,  it  is  fi-equently  used  as  a  contract-specified  requirement.  It  is  not  a  good 
definition  to  use  when  estimating  the  true  combat  potential  for  most  systems  because  it 
provides  no  indication  of  the  time  required  to  obtain  required  field  support.  This  term 
should  normally  not  be  used  to  support  an  operational  assessment. 

A  third  measure.  Achieved  Availability  (Aa),  is  frequently  used  during  development  testing 
and  initial  production  testing,  when  the  system  is  not  operating  in  its  intended  support  en¬ 
vironment.  It  is  defined  over  a  specific  period  of  time  and  relates  the  time  the  equipment 
is  in  use,  i.e.,  operating  time  (OT),  to  the  sum  of  the  OT  plus  the  corrective  maintenance 
time  (TCM)  plus  the  preventive  maintenance  time  (TPM). 

Aa=  OT 

OT  +  TCM  +  TPM 

Achieved  availability  is  much  more  a  system  hardware-oriented  measure  than  is  operational 
availability,  which  considers  operating  environment  factors.  It  is,  however,  dependent  on  the 
preventive  maintenance  policy,  which  is  greatly  influenced  by  nonhardware  considerations. 

To  summarize,  operational  availability  is  the  most  desirable  form  of  availability  to  be  used 
in  helping  assess  a  system’s  potential  under  fielded  conditions.  Achieved  availability  and. 
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to  a  lesser  degree,  inherent  availability  are  primarily  the  concern  of  the  developing  organi¬ 
zation  in  its  interface  with  the  contractor. 

10.3.3  RAM  Has  Many  Other  Terms 

The  terminology  used  is  not  standard  and  tends  to  depend  on  the  Service  and/or  system. 
Be  sure  you  have  a  clear  idea  of  what  the  RAM  terms  mean  in  the  requirements  docu¬ 
ments  and  the  contract  specification.  The  American  Society  for  Quality  Control  published 
a  361 -page  book  entitled,  Reliability,  Availability,  and  Maintainability  (RAM)  Diction¬ 
ary,  by  Tracy  Omdahl.  This  is  the  “Webster’s  Dictionary”  of  RAM  terms. 

The  metrics  used  in  most  engineering  technologies  tend  to  be  natural  phe¬ 
nomena  such  as  speed,  rate  of  turn  and  payload.  While  they  may  require 
very  careful  definition  and  control  of  the  way  they  are  measured,  the  met¬ 
rics  themselves  are  not  subject  to  different  definitions... 

RMS  (rehability,  maintainabihty,  and  supportability)  however,  uses  metrics 
that  are  somewhat  specialized  rather  than  naturally  defined.  As  a  result, 
there  are  more  than  2000  terms  defined  in  documents  reviewed  so  far, 
many  of  which  have  the  same  meaning  but  different  definitions. 

Society  of  Automotive  Engineers  RMS  Newsletter,  Apr  1990 

10.3.4  RAM  Requirements  and  Terms 

10.3.4.1  RAM  in  the  User’s  Requirements  Documentation. 

10.3.4.1.1  Mission  Need  Statement  (MNS) 

The  MNS  provides  the  information  listed  below; 

•  identifies  mission  need  or  deficiency  in  general  terms  (not  the  solution)  and 

•  establishes  very  general  system  constraints  including  logistics  (five  pages 
only). 

10.3.4.1.2  Assessment  of  Alternatives  (AOA) 

The  AOA  describes  the  following  information: 

•  trade  studies  performed  during  the  Concept  Exploration  phase, 

•  alternative  solutions,  which  balance  effectiveness  (lethality,  deployability, 
availability,  and  dependability)  and  affordability  (costs  for  deployment, 
production,  operations,  and  support),  and 

•  best  solution  identification. 
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10.3.4.1.3  Operational  Requirements  Document  (ORD) 
In  the  ORD,  the  following  items  are  included: 


•  solution-oriented  focus  on  the  preferred  solution  selected  following  the 
AOA,  and 

•  user  definition  of  system  RAM  parameters  in  operational  terms. 

10.3.4.2  Measures  of  Systems  Readiness.  The  “user”  or  “operator”  has  various  measures 
highlighted  in  the  ORD  that  must  be  translated  by  the  program  office  into  specifications. 
Here  is  a  sample  of  user  measurements  compared  to  the  MTBF  (reliability)  and  MTTR 
(maintainability)  often  used  in  contractual  specifications: 

OBJECTIVE  AREA  RELIABILITY  MAINTAINABILITY 

(MTBF)  (MTTR) 


Increase  Readiness 

(MTTRS) 

Increase  Mission 
Success 


Decrease  Maintenance 
Personnel  Costs 

Decrease  Logistics 
Support  Costs 


-  Operational  Effectiveness - 

Mean  Time  Between  Mean  Time  to  Restore 

Downing  Events  (MTBDE)  System 


Mean  Time  Between  Mean  Time  to  Restore 

Critical  Fadures  (MTBCF)  Functions  (MTTRF) 

- Ownership  Costs . 

Mean  Time  Between  Mean  Labor  Hours  Per 

Maintenance  Actions  (MTBMA)  Maint.  Actions  MMH/MA 

Mean  Time  Between  Parts  Costs/Removal 

Removals  (MTBR) 


We  can  now  see  the  connection  between  the  two  goals  of  a  good  RAM  program  (higher  op¬ 
erational  effectiveness  and  lower  ownership  costs),  the  users’  ORD  measurements,  and  the 
contractual  measurements  (MTBF  or  MTTR  in  this  case).  Remember,  the  developmental  test¬ 
ers  test  to  contractual  specifications;  and  the  operational  testers  test  to  the  ORD  thresholds. 
The  operational  user,  the  program  offices,  and  the  contractor  often  get  very  confused  over  the 
process  of  translating  ORD  numbers  to  contract  specs  and  vice  versa. 

10.3.4.3  Contractual  Terms  —  MTBF.  The  contract  must  be  specific!  The  user,  the  pro¬ 
gram  office,  and  the  contractor  must  understand  and  agree  not  only  to  the  RAM  terms  in 
both  the  ORD  and  specification  but  also  to  the  definition  of  ‘failure”  to  be  used  in  the 
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contractual  specification.  When  test  results  are  compiled,  the  user  sometimes  misunder¬ 
stands  the  meaning  of  the  results  relative  to  the  ORD  thresholds  set  forth. 

Example:  What  counts  for  a  contractual  definition  of  ‘failure?” 

As  a  technique,  the  following  ean  be  used.  Failure  categories:  All  events  occurring  during 
reliability  tests  are  classified  as  relevant  or  nonrelevant.  Relevant  failures  are  further  clas¬ 
sified  as  chargeable  or  nonchargeable.  Make  sure  that  failure  classifications  are  defined  on 
the  contract  and  that  the  contractor,  user,  and  System  Program  Office  (SPO)  meet  and 
agree  on  these  terms  early  in  the  process. 

Examples  of  contractually  chargeable,  relevant  events: 

•  failures  due  to  equipment  or  part  design, 

•  failures  due  to  manufacturing  defects  in  equipment  or  parts, 

•  intermittent  events,  and 

•  unverified  failures  (can  not  duplicate). 

Examples  of  nonchargeable  and/or  nonrelevant  events: 

•  installation  damage, 

•  accident, 

•  mishandling, 

•  normal  operating  adjustments, 

•  events  caused  by  human  error,  and 

•  software  errors  corrected  and  verified  in  subsequent  testing. 

It’s  easy  to  see  the  problems  a  program  manager  can  face  when  test  results  return  with  many 
failures  reported.  But  are  they  failures?  Do  you  want  lawyers  to  determine  the  definition? 

10.3.5  R&M  Allocation 

The  operational  user  requirements  and  goals  are  generally  at  the  system  level.  These  need 
to  translate  customer  system  requirements  to  lower  levels  of  assembly: 

•  subsystem, 

•  line  replaceable  unit  (LRU), 

•  shop  replaceable  unit  (SRU), 

•  individual  components, 

•  allocation  (shows  relationship  between  individual  items  and  whole  system),  and 

•  design  target  for  engineers. 
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Method  1  -  For  known  equipment  in  a  new  application,  for  example,  we  would  allocate 
100  hours  MTBF,  using  F-16  radar  with  50  hours  MTBF  in  the  F-22  and  expecting  50 
percent  of  the  environmental  stresses  in  the  F-22. 

Method  2  -  When  using  a  weighted  model  and  expected  parts  count,  the  more  parts  to  a 
subsystem,  the  more  failures  are  allocated  to  that  subsystem. 

Example:  Having  3  subsystems  with  a  total  parts  count  of  1000  and  with  the  #3  subsys¬ 
tem  having  400  parts  or  40  percent  of  the  total,  we  would  allocate  to  #3  using  the  follow¬ 
ing  formula:  (failure  rate)  X  (.4)  =  allocation  for  subsystem  #3. 

IMPORTANT:  Comparative,  allocated,  predicted,  and  measured  (test  results)  values 
are  used  in  the  design  process.  These  values  impact  personnel,  planning,  support 
equipment  requirements,  etc.,  throughout  the  system  design  process.  Generally,  allo¬ 
cated  values  are  used  as  the  basis  for  rehabihty  requirements  in  subcontractor  and 
vendor  specifications. 

10.4  RELIABILITY  TECHNIQUES 

10.4.1  Contracting  for  Reliability 

10.4.1.1  Requirements.  To  attain  an  increase  in  combat  capability,  operational  thresholds 
and  goals,  these  requirements  must  be  communicated  in  clear  operational  terms.  Then, 
these  operational  terms  must  be  properly  translated  into  viable  contractual  terms  under¬ 
stood  and  accepted  by  the  user,  program  office,  and  the  contractor.  The  following  items 
are  important  to  remember: 

•  requirements  must  be  clear; 

•  simple  design  requirements  should  make  a  system  cheaper  to  produce, 
operate,  and  maintain;  and 

•  requirements  should  be  testable. 

10.4.1.2  Source  Selection.  Source  selection  is  the  most  important  contractor  motiva¬ 
tional  factor.  In  a  source  selection  for  a  new  or  modified  system,  RAM  must  be  singled 
out  as  specific  evaluation  criteria. 

10.4.1.3  Incentives  and  Warranties.  Incentives  reward  contractors  for  exceeding 
minimum  program  requirements.  Warranties  hold  contractors  responsible  for  sus¬ 
taining,  in  the  operational  environment,  the  performance  levels  for  which  incentives 
have  been  paid.  Try  a  fixed-price  warranty  repair  contract  with  a  warranty  period  of 
three  to  five  years  -  long  enough  for  the  contractor  to  demonstrate  compliance.  If  the 
system  does  not  meet  the  warranted  level,  consignment  spares  should  be  included  to 
maintain  combat  capabihty  while  repairs  and  engineering  improvements  are  made. 
Additionally,  the  matrix  in  Table  lOA,  taken  from  the  Flexible  Sustainment  Guide, 
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January  1997,  gives  an  idea  of  the  impact  that  reliabihty  has  in  selecting  from  a  mul¬ 
titude  of  warranty  types. 


TABLE lOA 

WARRANTY  CONSIDERATION  MATRIX 


WARRANTY  TYPE  | 

CONDITION 

R 

I 

w 

R 

& 

M 

I 

W 

T 

& 

R 

I 

G 

M 

T 

B 

F- 

V 

T 

A 

G 

L 

S 

c 

G 

W 

0 

s 

C 

L 

R 

M 

P 

C 

s 

p 

L 

R 

& 

M 

W 

c 

R 

W 

R 

W 

u 

F 

G 

C 

S 

L 

R 

E 

& 

A 

Spare  -  Reliability 
exceeds  system  life 

X 

X 

m 

X 

X 

X 

X 

X 

X 

Spare  -  Reliability 
exceeds  technology  cycle 

■ 

■ 

X 

X 

i 

■ 

X 

X 

X 

X 

X 

X 

X 

1 

■ 

X 

■ 

■ 

X 

X 

■ 

■ 

X 

X 

X 

X 

X 

■ 

X 

X 

X 

X 

Competitive  Commercial 
Repair 

H 

H 

X 

■ 

■ 

■ 

X 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

X 

Contract  repair  (costs 
less  than  organic 

X 

X 

X 

H 

■ 

X 

■ 

■ 

■ 

X 

■ 

■ 

■ 

X 

Repair  -  Organic  less 

_ 

_ 

B 

_ 

a 

_ 

_ 

WARRANTY  LEGEND 

RIW 

Reliability  Improvement  Warranty 

SPL 

Spare  Parts  Level  Warranty 

R&MIW 

Reliability  &  Maint.  Improvement  Warranty 

R&MW 

Reliability  &  Maintainability  Warranty 

T&RIG 

Test  &  Repair  Improvements  Guarantee 

CRW 

Component  Reliability  Warranty 

MTBF-VT 

Mean  Time  Between  Failures- Verification 

RW 

Reliability  Warranty 

AG 

Availability  Guarantee 

UFG 

Utility  Functions  Guarantee 

LSCG 

Logistics  Support  Costs  Guarantee 

UL 

Ultimate  Life  Warranty 

WOS 

Warranty  of  Supplies 

CSL 

Commercial  Service  Life  Warranty 

CLR 

Chronic  LRU  Guarantee 

R&EA 

Repair  and  Exchange  Agreements 

MPC 

Maximum  Parts  Cost  Guarantee 

10.4.1.4  Tools.  Section  17.5  of  this  Guide  describes  two  contract-related  tools, 
LOGPARS  and  Turbo  Streamliner.  Each  tool  has  sections  devoted  to  Request  for  Pro¬ 
posal  (RFP)  construction,  including  RAM  references.  Website  addresses  for  these  tools 
are  provided  in  Section  17.5. 

10.4.2  Predesign:  Research  and  Analysis 

Accurately  define  mission,  environmental,  and  real-life  profiles,  including  the  following: 

•  consider  past  experiences  with  field  operations  and  lessons  learned; 

•  define  equipment  environment  (fuel,  oil,  static  electricity);  and 

•  define  natural  environment  (solar,  humidity,  salt,  etc.). 
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10.4.2.1  Example  1:  Natural  Environment.  A  relative  humidity  of  approximately  35 
percent  is  normal  for  electronics.  More  humidity  causes  corrosion  and  less  humidity 
causes  static  electricity  problems.  The  Royal  Air  Force  performed  experiments  with 
dehumidification  units.  The  tests  showed  a  22  percent  reduction  in  avionics  servicing 
for  both  the  F-4  Phantom  and  the  Tornado  and  an  18  percent  in  the  Nimrod.  When 
these  tests  were  reported  in  the  CODERM  Newsletter,  September  1993,  another  result 
was  noted,  “Added  bonus...  the  cabin  of  the  Nimrod  no  longer  smells  Uke  a  wet  dog  in 
a  duffel  coat.” 

10.4.2.2  Example  2:  Transportation  and  Storage.  Maverick  missiles  were  placed  in  stor¬ 
age  containers  and  transported  by  ship  to  the  Mid  East.  These  containers  were  not  in¬ 
spected  upon  delivery,  and  the  units  were  placed  in  desert  open-air  storage.  One  year 
later,  the  containers  were  opened;  and  they  contained  6-8  inches  of  salt  water!  The  fiber¬ 
glass  containers  did  not  seal  properly  and  the  plugs  had  blown  out  in  shipment. 

10.4.2.3  Tool.  Sometimes,  part  of  the  disparity  between  laboratory  test  results  for  reli¬ 
ability  and  initial  operations  test  results  can  be  a  problem  with  packaging.  At  the  follow¬ 
ing  address  this  office  will  do  the  packaging  engineering  for  you! 

ASCffHC 

Eglin  AFB,  FL  32542-5000 
DSN  872-4609 
(904)  882-3779 

10.4.3  Design  Process 

The  steps  in  the  design  process  include: 

•  performing  trade  studies; 

•  performing  system  and  item  analyses  of  the  candidate  design; 

•  establishing  design  criteria;  and 

•  making  detailed  decisions  that  transform  requirements,  resources,  and  con¬ 
straints  into  a  design. 

10.4.4  RAM  Analyses 

Four  of  the  more  common  techniques  used  in  RAM  analyses  are; 

•  reliability  prediction  methods; 

•  failure  mode,  effects,  and  criticahty  analysis; 

•  maintainabihty  analysis;  and 

•  reliabihty  centered  analysis. 
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10.4.4  Tools  for  Analysis 


10.4.4.1  Redundancy.  Because  of  the  impact  to  logistics  reliability,  the  PM’s  interest 
should  be  great  if  the  contractor  proposes  redundancies  to  meet  mission  reliability  re¬ 
quirements.  Space  weight  and  power  provisions  must  be  accounted  for.  Additionally, 
logistics  support  must  be  included  when  calculating  support  requirements  and  costs. 

10.4.4.1.1  Exercise.  The  initial  design  for  a  system  has  three  subsystems  (A,  B,  &  C)  in 
series  (each  must  work  for  the  system  to  be  successful).  Their  respective  reliability  factors 
for  the  components  of  a  series  system  are  shown  below: 


- — [RA  (.95)] - [RB  (.90)1 - [RC  (.80)] 

Reliability  of  the  system  =  R  x  Rb  x  Rc  or  (.95)  x  (.90)  x  (.80)  =  ??? 


What  if  the  user  requirement  is  .80  for  the  system?  Does  the  above  system  meet  the  re¬ 
quirement?  Even  without  a  calculator,  we  know  right  away  that  the  system  is  below  .80 
since  the  lowest  reliability  of  a  subsystem  is  .80. 

What  are  the  options  if  you  wish  to  improve  the  system  reliability?  What  are  the  risks 
and/or  tradeoffs?  What  if  you  choose  redundancy? 

1 0.4.4. 1 .2  Redundancy  Characteristics. 

When  choosing  redundancy,  there  are  three  major  items  to  consider: 

1)  The  level  of  redundancy  application,  e.g.,  piece  part,  black  box,  or  complete  re¬ 
dundant  systems; 

2)  The  redundant  element’s  operating  state  (Examples:  An  airport,  which  is  operating 
two  separate  ground-control  radar  units  at  all  times,  has  active  redundancy.  Car¬ 
rying  a  spare  tire  in  your  trunk  is  passive  redundancy.);  and 

3)  The  method  used  to  activate  the  redundant  element.  (The  driver  of  a  car  loses 
mission  time  changing  a  flat  tire.  An  electronic  switching  network  senses  a  failure 
and  automatically  switches  without  loss  of  mission  time.) 

10.4.4.3.3  Redundancy  Summary 

•  Redundancy  can  help  improve  mission  reliability. 

•  Redundancy  generally  decreases  logisties  reliability  and  increases  support  costs. 

•  Try  to  in^rove  the  rehability  of  a  single  unit  whenever  possible;  use  redundancy  as 
a  last  option. 
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10.4.4.2  Failure  Modes.  Effects,  and  Criticality  Analysis  (FMECA).  FMECA  is  a  proce¬ 
dure  that  analyzes  each  potential  system  failure  mode  to  determine  its  results  or  effects  on 
the  system  and  to  classify  each  potential  failure  mode  according  to  its  severity.  The  pur¬ 
pose  is  to  provide  a  safer,  more  reliable  initial  design.  See  Figure  10-2.  MIL-STD  1629A 
is  being  rewritten  to  become  a  Society  of  Automotive  Engineers  standard.  Ford  Motor 
Company  uses  the  FMECA  procedure  but  uses  a  different  criticality  methodology.  Some¬ 
times  logisticians  and  systems  engineers  wish  to  perform  an  FMECA  down  to  the  piece 
part;  this  can  be  very  expensive  and  is  not  always  needed.  The  FMECA  also  helps  to 
identify  single  points  of  failure  that  show  how  the  failure  of  one  component  can  cause  the 
failure  of  the  whole  system.  Single  points  of  failure  must  be  identified  and  eliminated 
during  the  design  process.  To  provide  a  better  understanding  of  a  typical  analysis,  a  sam¬ 
ple  page  from  a  FMECA  is  presented  in  Figure  10-3. 

10.4.4.2.1  Steps  in  the  FMECA  Process: 

•  What  is  the  function  of  the  system?  How  does  it  work? 

-  parts? 

-  interfaces? 

-  software? 

•  How  many  ways  can  it  malfunction? 

•  What  happens  if  an  item  malfunctions? 

-  to  the  next  higher  assemblies? 

-  system? 

-  What  is  the  risk? 

-  how  critical  is  each  malfunction? 

-  what  is  probability  that  it  can  happen? 


FAILURE  MODES,  EFFECTS 
AND  CRITICALITY  ANALYSIS  (FMECA) 

•  Definition: 

-  a  review  that  examines  potential  failure  modes  to 
determine  their  effects  on  equipment 

-  employs  a  “bottoms-up”  approach 

•  Uses: 

-  shows  areas  that  need  corrective  action 

-  ranks  severity  of  failures/safety 

-  identifies  reliability-critical  components 

-  provides  input  data  to  systems  engineering/logistics 


Figure  10-2:  Failure  Modes,  Effects,  and  Criticality  Analysis 
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SYSTEM  NAME 

SPACE  SHUTTLE  MP  SRM 

10-00 

SUBSYSTEM  NAME 

SRM  CASE 

104)6 

COMPONENT  NAME  AND 

PART  NO. 

CASE  ASSEMBLY,  FORWARD  10-05-01 
SEGMENT 

1U501 47-08 

AUTHOR  AND 

COMPANY 

W.  L.  HANKINE 

THIOKOL  CORPORATION 

DATE 

JUNE  1983 

REVISION 

MISSION 

PHASE 


COMPONENT  FAILURE  MODE 
AFFECTED  COMPONENT  PARTS 
REASONS  FOR  FAILURE 


ASSEMBLY  JOINTS  LEAK.  QUANTITY 

PART  NO.  PART  NAME  COMPONENT 

1U50131-09  CASESEGMEMT.CYLtNDER  2 

1U51473-01  CASE  SEGMENT.  FORWARD  1 

1US0228-24  packing  (O-RINGS)  2/JOIMT 

1U100269-01  TEST  PLUG  1/JOIMT 

1U50228-1S  PACKING  (TEST  PLUG)  1/PLUG 

1.  TANG-A-DIAMETER  EXCEEDS  UPPER  LIMIT  OR  SURFACE 
FINISH  NONCONFORMING,  OR  IS  GOUGED'  OR  BURRED 
ACROSS  BOTH  SEAL  SURFACES. 

2.  CLEVIS  NONCONFORMING  (DIAMETER,  THICKNESS,  FINISH). 

3.  CLEVIS  O-RING  GROOVES  EXCEED  WIDTH  AND/OR  DEPTH 
UPPER  LIMITS  OR  CORRODED. 

4.  0-RINGS  NONCONFORMING  OR  DAMAGED  DURING  ASSEM¬ 
BLY. 

5.  LEAK  CHECK  PLUG  LOOSE  OR  WITHOUT  O-RING.  INNERMOST 
SEAL  INEFFECTIVE  PER  1  ABOVE  OR  THE  CONDITIONS  OF  O- 
RING  ARE  PER  4  ABOVE. 

6.  FOREIGN  MATERiAL  iN  ORING  GROOVES. 

7.  IGNITER  FLANGE  NONCONFORMING,  FLATNESS  FINISH. 

8.  CASE  ASSEMBLY  JOINT  ROTATION  CAUSES  “LIFT-OFF”  FROM 
SECONDARY  O-RING  (PRIMARY  O-RING  WILL  REMAIN  IN 
COMPRESSION). 

9.  EXPANSION  OF  CLEVIS  GAP  BECAUSE  OF  RESIDUAL  STRAINS 
RESULTING  FROM  MANUFACTURING  PROCESSES. 


COMPONENT  FUNCTION 


FAILURE  EFFECT  ON 

A.  SUBSYSTEM  FUNC'nON 

B.  SYSTEM  FUNCTION 

C.  MISSION 

D.  VEHICLE  AND  PERSONNEL 


CRITICAUTY 

CATEGORY 


CONTROL  METHODS 
TO  INSURE  A 
RELIABLE  PRODUCT 


A.  HIGH  TEMPERATURE  GAS  FLOW 
WILL  CAUSE  METAL  EROSION 
AND  PROBABLE  BURNTHROUGH 
AND  CASE  BURST. 

B.  CATASTROPHIC  FAILURE  OF 
SRM. 

C.  MISSION  LOSS. 

D.  VEHICLE  AND 
PERSONNEL  LOSS] 


(1) 


(1R) 

(1R) 


(1R) 

(1) 


(1R) 

OR) 

OR) 


OR) 


1.  TRAINED,  QUALIHED 
MACHINIST  TO  PERFORM 
MACHINING  OPERATION. 

2.  SPECIAL  PROFILE  TEMPLATE 
TO  CONTROL  LATHE  CUTTING 
HEAD. 

3.  100%  INSPECTION  OF  TANG- 
DIAMETER,  CLEVIS.  DIMEN  - 
SIGNS  AND  O-RING  GROOVES 
USING  PI  TAPE  AND  STANO- 
DARD  MEASURING  INSTRU¬ 
MENTS  .  SURFACE  RNiSH 
SAMPLE  INSPECTED  BY 
SURF-INDICATOR. 

7.  A.  TRAINED,  QUALIFIED 
MACHINIST  TO  PERFORM 
MACHINING  OPERATION. 

B.  100%  INSPECTION  OF 
IGNITER  FLANGE  FLATNESS 
BY  TiR  READOUT  FINISH  IS 
SAMPLE  INSPECTED  USING 
SURF-INDICATOR. 


PAGE 


OF 


Figure  10-3:  Sample  Page,  Failure  Modes,  Effects,  and  Criticality  Analysis 

10.4.4.2.2  Benefits  of  FMECA: 

•  less  initial  redesign 

•  less  test-analyze  and  fix 

•  more  likely  to  meet  schedule  and  cost  goals 

•  greater  customer  satisfaction 

-  lower  warranty  claims 

-  fewer  liability  claims  (Lawyers) 

10.4.5  Reliability  Design  for  Electronics 

Generally,  reliability  prediction  techniques  have  been  based  upon  empirical  models  derived 
from  field  data  found  in  both  military  and  commercial  handbooks.  In  the  next  section,  you 
will  see  some  of  the  problems  involved  and  hear  about  an  alternative  called  Physics  of 
Failure  (POF).  Also,  the  FMECA  and  redundancy  are  used  in  designing  electronic  sys¬ 
tems.  Additional  tools,  such  as  a  parts  control  program  and  electronics  derating,  are  also 
used  to  improve  the  reliability  for  electronic  systems. 

10.4.5.1  Parts  Control  Program.  A  large  percentage  of  hardware  is  unreliable  due  to  pur¬ 
chased  parts.  Many  may  be  immature,  less  reliable,  not  tested/qualified  for  your  applica- 
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tion.  The  purpose  of  a  parts  control  program  is  to  assist  in  selection  and  use  of  parts  in 
new/modified  equipment.  A  parts  control  program  enhances  standardization,  interchange- 
ability,  reliability,  and  maintainability.  It  will  also  conserve  scarce  resources  you  would 
need  to  develop  components.  The  quality  of  the  parts  is  a  factor  in  predicting  the  reliabil¬ 
ity  of  the  electronic  components  up  to  system  level.  Currently  handbooks  are  used  in  pre¬ 
diction  methodology  and  are  currently  under  tremendous  criticism.  Handbooks  such  as 
MIL-HDBK-217F  use  field  data  in  their  methodology.  The  results  are  controversial. 
Proponents  believe,  as  a  minimum,  the  results  allow  for  quick  comparisons  to  be  made. 
(MIL-HDBK-217F  is  to  be  retained  as  a  handbook  until  the  Institute  of  Electrical  and 
Electronic  Engineers  (IEEE)  or  a  similar  organization  develops  a  suitable  replacement.) 

10.4.5.2  Tools.  The  Military  Parts  Control  Advisory  Group  (MPCAG)  operates  an  on¬ 
line  parts  database,  prepares  standardized  part  design  documentation,  and  tests  parts  to 
qualify  vendors.  (The  qualifying  vendors  program  is  currently  under  scrutiny.)  Four  De¬ 
fense  Logistics  Agency  (DLA)  organizations  can  help  with  parts  control: 

•  Defense  Electronic  Supply  Center  (DESC/EPA),  Dayton,  OH 
(513)296-5431 

Tubes,  resistors,  capacitors,  semiconductors,  relays,  and  fiber  optics. 

•  Defense  Industrial  Supply  Center  (DISC/ESM),  Philadelphia,  PA 
(215)  697-4395/3007 

Fasteners,  seals,  springs,  and  bearings 

•  Defense  General  Supply  Center  (DGSC/SEA),  Richmond,  VA 
(804)  275-4885 

Refrigeration  components,  lamps,  electrical  hardware,  lubricants,  batteries  etc. 

•  Defense  Construction  Supply  Center  (DCSC/SSI),  Columbus,  OH 
(614)  236-2205/2886 

Gears,  pulleys,  belts,  hoses,  tubing,  valves,  etc. 

10.4.5.3  Parts  Derating.  Derating  establishes  a  design  margin  to  provide  the  robustness 
necessary  in  the  operational  environment.  Derating  is  the  practice  of  limiting  mechanical, 
thermal,  and  electrical  stresses  on  components  to  enhance  reliability;  it  also  increases  the 
reliability  of  individual  components  and  thereby  the  reliability  of  the  system.  Derating  is 
always  a  compromise  among  weight,  size,  cost,  and  failure  rate.  Procedures  vary  with 
different  components  when  using  derating.  Microcircuits  are  derated  as  a  function  of  op¬ 
erating  junction  temperature.  Mechanical  parts  are  derated  in  terms  of  tension,  torsion, 
temperature,  and  other  limits. 

CAUTION:  “Cookbook”  derating  criteria  generally  do  not  allow  you  to  quantify  the 
magnitude  of  reliability  improvement. 
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10.4.5.4  Reliability  Prediction.  Prediction  Methods  include  the  following: 


•  parametric  estimations,  e.g.,  failure  rate  as  a  function  of  weight  of  avionics, 

•  engineering  models,  and 

•  models  that  are  based  upon  historical  reliability  data  (handouts). 


How  accurate  are  the  values  when  a  manufacturer  states  that  a  transceiver  has  a  “MTBF 
greater  than  7000  hours”?  How  did  the  manufacturer  come  up  with  the  value?  These  are 
some  of  the  questions  commercial  and  military  program  offices  have  been  struggling  with 
for  years.  MIL-HDBK  217  accounts  for  stress,  environment,  and  quality  as  factors  for 
predicting  reliability. 


10.4.5.4.1  Example:  The  failure  rates  for  a  hypothetical  circuit  board  were  predicted  us¬ 
ing  various  failure  rate  models.  (Source:  1986  RAMS  Proceedings,  p.  162).  For  the  same 
device  (14  components),  the  following  were  predicted  failures  per  million  operating  hours: 

Predicted  Failures 

Model  Per  Million  Hours 


Bell  Communications  Research  12,502 

MIL-HDBK-217  715,784 

British  Telecom  1 ,258 

CNET  (French)  16,714 

Nippon  Telephone  and  Telegraph  9,525 


NOTE:  “MIL-HDBK  217  is  not  intended  to  predict  field  reliability  and,  in 
general,  does  not  do  a  very  good  job  in  an  absolute  sense.  The  reasons  for 
this  are  numerous  including  different  failure  definitions  for  field  problems 
that  MIL-HDBK-217  does  not  account  for...” 

RAC  Technical  Brief 
April  1990 

10.4.5.5  Comparative  Analysis.  Comparative  analysis  is  a  method  for  predicting  the  op¬ 
erational  reliability  or  maintainability  characteristics  of  systems  yet  to  be  fielded.  Using 
this  method,  engineers  do  the  following: 

•  break  down  the  system  into  subsystems  and  identify  the  most  comparable  sub¬ 
systems  from  other  similar  systems. 
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•  extract  field  data  on  existing  systems, 

•  combine  engineering  factors  and  field  data, 

•  compare  predicated  v.  actual  operating  environments,  and 

•  compare  predicted  v.  actual  operating  environments. 

Example.  F-22  flight  controls  would  use  a  combination  of  F-15  and  F-16  flight  controls  as 
a  baseline.  Engineers  determine  that  the  electrical  components  would  have  a  two-  to  five¬ 
fold  factor  improvement  in  the  F-22.  Since  F-15  and  F-16  field  data  has  a  Mean  Time 
Between  Maintenance  inherent  (MTBMi)  of  70  hours,  engineers  would  predict  140  to  350 
hours  MTBMi  for  the  electrical  components  of  the  F-22  flight  control  system. 

Bottom  Line:  The  prediction  process  today  is  not  ideal.  Comparative  methods  are  better 
than  handbooks  at  present.  This  data,  some  of  it  bad,  some  of  it  good,  finds  its  way  into 
the  support  analyses  with  resultant  problems  during  initial  fielding. 

10.4.5.6  Physics  of  Failure  (POF).  This  method  holds  much  greater  promise  than  the  old 
handbook  method.  One  drawback  of  POF  is  the  time  it  takes  to  perform  the  analysis.  The 
following  are  quotes  and  excerpts  from  Michael  W.  Deckert  article,  “Physics  of  Failure:  A 
Science  Based  Approach  to  Ultra  High  Reliability,”  Program  Manager,  Sept.-Oct.  1994: 

“Key  trade-offs  between  conunercial  and  military  specification  compo¬ 
nents,  ruggedized  vs.  nonruggedized  boards,  emerging  vs.  traditional  tech¬ 
nology,  and  design  layout  occur  early  in  a  program  and  can  significantly 
impact  the  rehability  and  life-cycle  costs  of  a  system.  The  POF  modeling 
and  simulation  tools  provide  program  managers  and  system  designers  with 
a  science  and  engineering  based  approach  for  evaluating  these  types  of 
trade-offs  that  can  impact  a  program.” 

The  POF  approach  uses  modeling  and  simulation  techniques  to  identify  first-order  failure 
mechanisms  prior  to  physical  testing.  In  addition,  the  POF  approach  scientifically  evalu¬ 
ates  new  materials,  structures,  and  technologies  by  designing  tests,  screens,  safety  factors, 
and  accelerated  simulation. 

10.4.5.6.1  Impacts  of  the  POF  are  listed  below: 

•  POF  tools  can  be  used  to  determine  failure  mechanisms  and  assist  in  acceler¬ 
ated  test  design. 

•  POF  concepts  can  improve  depot  maintenance  in  three  areas:  failure  verifica¬ 
tion  and  isolation,  improved  reliability  after  repair,  and  improved  repair  verifi¬ 
cation. 
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•  Currently,  unfailed  electronic  components  are  assumed  to  be  “as  good  as  new” 
if  they  have  not  failed.  With  POF,  a  more  reliability  centered  maintenance  ap¬ 
proach  would  be  possible,  e.g.,  timed  change  of  a  circuit  card  assembly  before 
actual  failure. 

•  Using  the  POF,  an  Environmental  Stress  Screening  (ESS)  could  be  more  accu¬ 
rately  designed  to  determine  how  much  useful  life  remains  after  the  screening  is 
performed. 

•  Currently  the  FMECA  assumes  that  integrated  circuits  are  failed,  either  opened 
or  closed.  The  FMECA  method  does  not  account  for  intermittent  failures. 
Using  the  POF  method’s  automated  assessment  tools,  failure  times,  sites,  and 
stress  drivers  for  the  key  failure  mechanisms  can  be  determined. 

10.4.5.6.2  POF  software  tools.  The  POF  computer  tools  can  reduce  the  number  of 
hardware  tests  by  improving  the  design  during  the  Pre-Milestone  0  through  Milestone  II 
phases  of  the  acquisition  life  cycle.  In  the  past,  reliability  growth  programs  began  after 
test  on  hardware  was  conducted  in  later  phases. 

The  University  of  Maryland  developed  CADMP-2;  it  is  used  to  assess  the  reliability  of  in¬ 
tegrated  circuit,  hybrid  and  multi-chip  module  packages. 

The  University  of  Maryland  developed  CALCE;  it  is  a  set  of  integrated  tools  for  the  de¬ 
sign  and  analysis  of  electronic  assemblies. 

10.4.5.6.3  Other  RAM  Tools.  The  Government-Industry  Data  Exchange  Program 
(GIDEP)  is  a  cooperative  activity  between  government  (including  the  Canadian  Depart¬ 
ment  of  Defense)  and  industry  participants  seeking  to  reduce  or  eliminate  costs  from  non- 
conforming  products.  With  GIDEP,  design  engineers  find  a  source  of  qualified  parts  in¬ 
formation.  Production  engineers  find  new  and  innovative  techniques  to  improve  produc¬ 
tion  processes  and  reduce  production  costs.  Reliability  engineers  use  the  failure  mode  and 
failure  rate  information  during  their  modeling  and  assessment  studies.  Logisticians  use 
mean  repair  time  data  in  projecting  logistics  support  and  resupply  requirements.  If  you 
want  to  join  the  GIDEP,  use  the  following  information: 

GIDEP  Operations  Center 
PO  Box  8000 
Corona,  CA  91718-8000 
DSN:  933-4677 
FAX:  (909)273-5200 

10.4.6  R&M  Testing 

10.4.6.1  Test.  Analyze.  Fix,  and  Test  (TAFT).  TAFT  is  a  disciplined  process  for  system¬ 
atically  detecting  and  eliminating  design  weaknesses  while  simulating  the  operational  envi- 
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ronment.  A  closed  loop  process,  TAFT  is  used  to  detect  failures,  feed  back  data,  analyze, 
redesign,  test,  and  verify  fixes.  TAFT  should  start  with  the  first  article  available  and  con¬ 
tinue  until  requirements  are  achieved. 

10.4.6.2  Failure  Reporting.  Analysis  and  Corrective  Action  System  (FRACAS). 

FRACAS  is  a  disciplined  and  aggressive  closed-looped  reporting  system  that  is  an  essen¬ 
tial  part  of  the  TAFT  process.  With  FRACAS,  failures  and  faults  of  both  hardware  and 
software  are  formally  reported.  Using  this  system,  analysis  is  performed  to  determine  fail¬ 
ure  cause  and  positive  corrective  actions  are  identified,  implemented,  and  verified  to  pre¬ 
vent  further  recurrence.  Early  implementation  of  FRACAS  has  the  following  advantages; 

•  cost  and  schedule  savings, 

•  time  to  assess  corrective  actions,  and 

•  time  to  address  all  failures  prior  to  full-rate  production. 

10.4.6.3  Environmental  Stress  Screening  (ESS).  ESS  stimulates  assemblies  with  thermal 
cycling  and  random  vibration  (as  a  minimum)  to  precipitate  these  defects  in  the  develop¬ 
mental  facihty  or  the  factory.  A  proper  ESS  program  wUl  be  applied  early  in  the  design 
and  development  phases  rather  than  in  the  later  production  phase.  An  effective  ESS  pro¬ 
gram  precipitates  defects  to  failure  at  the  lowest  level  of  assembly  and  does  not  damage 
equipment.  (A  common  goal  is  to  use  a  maximum  of  10  percent  of  component  life  to 
conduct  ESS.)  By  moving  detection  of  early  failures  from  the  field  to  the  factory,  great 
savings  can  be  attained.  Applied  early,  ESS  can  pay  for  itself  by  correcting  defects  and  by 
preparing  the  item  under  test  for  subsequent  reliability  development  testing. 

10.4.6.4  Reliability  Development  Test  (RDT).  The  heart  of  the  TAFT  process  is  the  for¬ 
mal  RDT.  The  RDT  is  designed  to  expose  the  equipment  to  thousands  of  operational  use 
cycles;  corrective  actions  are  incorporated  and  verified  during  the  test.  Considerable  ex¬ 
pense  and  resources  are  required  for  the  RDT  effort.  With  proper  emphasis  on  design 
fundamentals  (see  the  POF  section),  parts  control,  and  reducing  variability  during  manu¬ 
facturing,  the  expensive  RDT  process  wUl  not  be  overwhelmed  with  faUures  that  should 
have  been  eliminated  earlier.  Suggestions  on  conducting  a  Reliability  Testing  Program  are 
found  in  MIL-HDBK-781A,  1  April  1996.  However,  the  standards  committee  is  request¬ 
ing  assistance  in  locating  or  developing  a  suitable  industry  standard. 

10.4.6.4. 1  Example.  It  is  estimated  that  typical  costs  to  detect  and  remove  defects  in  the 
field  are  $15,000.  In  the  factory,  estimated  costs  to  detect  and  remove  defects  are  $1,500 
at  the  system  level,  $500  at  the  LRU  level,  $50  at  the  circuit  card,  and  approximately  $1  at 
the  piece  part  level. 

10.4.6.4.2  Tool.  The  Reliability  Toolkit:  Commercial  Practices.  1995  Edition,  is  an  ex¬ 
cellent  source  for  reliability  terms,  definitions,  and  engineering  processes,  such  as  require- 
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ments  definition,  analysis,  design,  and  testing.  For  $25,  you  can  get  a  copy  by  calling 
DSN  587-  2608  or  by  writing  to; 

Systems  Reliability  Division 
Rome  Laboratory 
Air  Force  Material  Command 
525  Brooks  Road 
Griffiss  AFB,  NY  13441-4505 

10.4.6.5  Manufacturing  RAM  Problems.  Premature  field-system  failures  are  often  caused 
by  parts  or  manufacturing  defects  introduced  during  production  and  repair.  Many  of  the 
latent  defects  that  result  firom  production  errors  and  weak  piece  parts  can  and  should  be 
eliminated  during  production. 

10.5  MAINTAINABILITY 

Maintainability  and  reliability  are  the  two  major  system  characteristics  that  combine  to 
form  the  commonly  used  effectiveness  index  -  availability.  It  is  inqjortant  when  we  con¬ 
sider  that  up  to  one-third  of  the  Services’  budgets  are  earmarked  for  maintenance.  Re¬ 
member  that  maintainability  is  a  design  consideration,  and  maintenance  is  a  consequence 
of  that  design.  As  discussed  previously,  there  are  two  maintenance  processes  -  preventive 
maintenance  and  corrective  maintenance. 

10.5.1  Reliability  Centered  Maintenance  (RCM) 

The  purpose  of  RCM  is  to  develop  a  scheduled  maintenance  program  with  the  goal  of  in¬ 
creasing  system  availability  by  identifying  failures  or  potential  failures  before  they  degrade 
system  effectiveness.  The  original  concept  of  RCM  came  fi-om  the  airline  industry.  RCM 
uses  information  from  the  FMECA  to  identify  items  that  are  the  most  critical  to  system 
availability.  The  RCM  analysis  process  uses  a  decision  tree  as  a  guide  for  complete  analy¬ 
sis  of  each  significant  item.  Preventive  maintenance  tasks  are  performed  on  a  scheduled, 
periodic  basis  to  prevent  failures  while  equipment  is  in  operation.  Do  not  confuse  this 
with  other  maintenance  tasks,  such  as  lubrication  and  adjustments,  needed  to  keep  systems 
in  operation.  Preventive  maintenance  tasks  can  be  divided  into  two  categories:  scheduled 
inspections  and  scheduled  removals. 

10.5.1.1  Example: 

•  Scheduled  inspection:  Your  automobile  should  be  inspected  every  15,000;  30,000; 
and  50,000  miles  according  to  the  owner’s  manual. 

•  Scheduled  removal:  The  timing  belt  on  your  automobile  should  be  removed  after 
50,000  miles  according  to  your  owner’s  manual. 
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10.5.2  Test  and  Diagnostics 

Repair  of  a  failed  item  begins  only  after  identification  of  the  failure.  Test  requirements 
should  be  matched  to  readiness  requirements  from  the  user  and  the  maintenance  concept 
required  for  the  system.  A  specification  may  require  90  percent  of  equipment  failures  to 
be  identified  at  the  organizational  level  of  maintenance  using  Built-In-Test  Equipment 
(BITE),  techmcal  manuals,  and  a  certain  level  of  skill  by  the  maintainer.  Our  need  for 
BITE  is  driven  by  operational  availability  requirements  that  do  not  permit  the  lengthy  re¬ 
pair  times  associated  with  detecting  and  isolating  failure  modes  in  microcircuits.  Fault 
detection,  e.g.,  the  engine  service  light  in  your  car,  and  fault  isolation,  e.g.,  a  fault  code 
telling  the  auto  mechanic  that  the  PCV  valve  is  stuck  closed,  usually  are  given  values  by 
the  user.  The  impact  of  inadequate  diagnostics  is  usually  manifested  in  long  maintenance 
delays  or,  if  the  Built-In-Test  (BIT)  is  faulty,  in  many  removals  with  a  retest  OK  at  higher 
levels  of  maintenance.  The  following  are  important  BIT/BITE  considerations: 

•  What  are  the  contractual  definitions  of  “failure”?  Should  the  contract  consider 
BIT  performance  only  in  regards  to  “BIT  addressable”  failures  (excluding 
problems  not  contractually  chargeable),  or  should  the  contract  consider  BIT 
performance  in  relation  to  overall  mission  reliability? 

•  What  failures  can  BITE  detect? 

•  Will  the  BITE  isolate  faftures  while  the  basic  system  is  in  the  operational  mode, 
or  must  the  system  be  shut  down  to  permit  isolation  procedures  to  be  per¬ 
formed? 

•  How  do  we  measure  percentage  of  false  alarms?  Was  the  BIT  routine  errone¬ 
ous?  Is  there  an  intermittent  out-of-tolerance  condition  somewhere? 

•  What  is  the  percentage  of  false  removals  allowed? 

10.5.3  Design 

Human  systems  integration  plays  a  major  role  in  maintainability  design.  Use  of  virtual  re¬ 
ality  to  check  access  and  visibility  among  many  factors  is  becoming  more  commonplace. 
Some  physical  design  features  affect  the  speed  and  ease  by  which  maintenance  can  be 
performed.  These  features  and  pertinent  questions  are: 

•  Accessibility:  Can  the  item  be  reached  easily  for  repair  or  adjustments? 

•  Visibility:  Can  the  item  being  worked  on  be  seen? 

•  Testability:  Can  system  faults  be  detected  and  isolated  to  the  faulty  replaceable 
assembly  level? 
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•  Complexity:  How  many  subsystems  are  in  the  system?  How  many  parts  are 
used?  Are  the  parts  standard  or  special  purpose?  Simple  systems  tend  to  be 
both  rehable  and  maintainable.  Simphcity  can  improve  both  reliability  and 
maintainabUity  by  minimizing  parts  and  interconnections  and  minimizing  the 
number  of  common  hand  tools.  (The  goal  is  to  have  no  peculiar  support 
equipment  or  tools  in  the  field.) 

•  Standardization  and  Interchangeability:  Can  the  failed  or  malfunctioning  unit  be 
swapped  around  or  readily  replaced  by  an  identical  unit  with  no  need  for  re- 
caUbration?  Standardization  of  systems,  subsystems,  parts,  tools,  and  proce¬ 
dures,  with  those  currently  used  in  the  field  can  lower  training  costs  and  risk  to 
readiness,  especially  during  initial  fielding  of  systems. 

Besides  physical  design  factors,  the  frequency  of  maintenance  actions  is  a  major  factor  in 
both  corrective  and  preventive  maintenance.  Rehability  can  have  significant  impacts  on 
corrective  maintenance;  and  design  features  such  as  self-check-out,  reduced  lubrication 
requirements,  and  self-adjustment  would  affect  the  need  for  preventive  maintenance. 

10.5.4  Maintainability  Demonstration  (M-DEMO) 

While  some  elements  of  maintainability  can  be  assessed  individually,  a  true  assessment  of 
system  maintainability  generally  must  be  developed  at  the  system  level  under  operating 
conditions  and  using  production  configuration  hardware.  The  purpose  of  an  M-Demo  is  to 
physically  show  that  the  equipment  can  be  maintamed.  Using  the  technical  manuals,  re¬ 
quired  tools,  and  other  support  equipment  necessary,  the  M-Demo  is  conducted  during 
late  Engineering  and  Manufacturing  Development  (EMD).  Using  the  actual  maintainers 
and  not  the  contractors  is  recommended  for  the  M-Demo.  MIL-HDBK-471A,  Maintain¬ 
ability  Demonstration,  12  June  1996,  outlines  suggestions  on  conducting  a  demonstration. 

10.6  RELIABILITY.  MAINTAINABILITY.  AND  SUPPORT  ABILITY  (RMS) 
BEST  PRACTICES 


This  section  contains  a  sampling  of  RMS  best  practices  for  the  purpose  of  communicating 
practices  that  one  or  more  commercial  or  military  organizations  have  adopted  and  reported. 
Most  of  the  items  were  gleaned  from  the  Best  Manufacturing  Practices  (BMP)  program,  a 
unique  industry  and  government  cooperative  technology  transfer  effort.  The  program  main¬ 
tains  a  Center  of  Excellence  (BMPCOE)  at  the  University  of  Maryland.  Over  100  participating 
commercial  and  military  organizations  have  been  surveyed,  and  best  practices  validated  during 
the  survey  are  documented  in  survey  reports.  The  reports  are  available  through  the  Defense 
Technical  Information  Center  (DTIC)  or  by  accessing  the  BMPnet.  Requests  for  recent  survey 
reports  or  inquiries  regarding  the  BMPnet  may  be  directed  to  the  Best  Manufacturing  Practices 
Program  (details  in  the  POC/Reference  Section  10.6. 17). 

The  examples  and  tools  that  follow  report  some  of  the  RMS  best  practices  that  have 
benefited  their  users.  Hopeftilly,  one  or  more  of  them  will  apply  to  the  reader. 
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10.6.1  Bar  Coding 

The  sometimes-difficult  decision  to  surrender  valuable  circuit-board  real  estate  to  accom¬ 
modate  board  markings  has  been  eased  by  developing  a  laser  marking  method.  This 
method  uses  bar  codes  to  place  part  of  the  serial  number  on  the  edges  of  boards.  Not  only 
can  the  boards  be  tracked  through  the  manufacturing  process  using  these  markings,  but 
also  they  can  be  more  easily  identified  among  densely  packed  adjacent  boards  during 
servicing  of  the  assembled  system.  Bar  coding  is  a  key  tool  for  the  accomplishment  of 
Configuration  Management. 

Hughes  Missile  Systems  Group,  Tucson,  AZ 

10.6.2  Special  Attention  to  Placement  of  Maintenance  Access  Panels  (V-22) 

Bell-Boeing  Vertol 

10.6.3  Maintenance  Management  Software  with  Graphical  User  Interface 

Now  that  people  are  using  chent/server  computing  and  graphical  user  interface,  the 
market  for  maintenance  software  is  growing  rapidly  and  is  predicted  to  top  $1  billion 
by  the  year  2000. 

Metropolitan  Atlanta  Transit  Authority  (MARTA) 

10.6.4  Automated  Test  Stations 

Lockheed  Martin-Government  Electronic  Systems  (LM-GES)  uses  three  AEGIS  auto¬ 
mated  test  stations  -  RF,  digital,  and  analog  -  for  testing  various  subassemblies.  Each  test 
station  integrates  varied  RF,  digital,  and  analog  measurements  into  a  single  connection  for 
testing  ease.  The  stations  allow  RF  measurements,  such  as  gain,  phase,  differential  phase, 
and  spectrum  analysis,  to  be  taken  on  solid-state  transmit/receive  modules  and  RF  devices 
in  high  volume  quantities.  The  automated  test  stations  use  a  computer-driven  UNIX  oper¬ 
ating  system;  and  they  contain  guided  probes,  which  are  capable  of  repeatable  measure¬ 
ments  needed  for  high-volume,  tight-tolerance  requirements.  Using  these  automated  test 
stations,  LM-GES  can  conduct  high-speed  testing  of  dynamic  and  numerous  specifications 
while  collecting  data  at  one  station.  The  stations  also  provide  accessibility  to  data  for 
analysis  of  individual  lot  diagnostics  for  research  and  development.  In  addition,  the  sta¬ 
tions  provide  a  production  platform  for  easy  conversion  to  other  programs  or  devices  (or 
maintenance  apphcations). 

Lockheed  Martin-Government  Electronic  Systems 

10.6.5  Networking  to  Provide  Total  Asset  Visibility/Integrated  Field  Service,  Etc. 

10-6.5.1  Field  Service  Communications.  Litton  Applied  Technology  Division  has  estab¬ 
lished  a  global  communications  network  linking  all  of  its  field  service  representatives 
throughout  the  world  directly  with  division  headquarters  and  with  each  other.  The  net¬ 
work  is  low  cost  but  provides  some  very  powerful  capabilities.  Each  field  representative 
has  a  Zenith  laptop  PC  equipped  with  a  3-1/2"  drive,  20  MB  hard  disk,  communications 
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modem,  and  a  dot-matrix  printer.  The  software  includes  Wordstar,  d-Base,  Lotus  1-2-3, 
Crosstalk,  and  a  graphics  package.  The  representatives  communicate  via  commercial  tele¬ 
phone  lines  and  electronic  mail  through  a  PC  at  division  headquarters.  Although  no  classi¬ 
fied  information  is  transmitted,  all  data  is  scrambled  to  assure  privacy. 

Litton  Applied  Technology  Division,  San  Jose,  CA 

10.6.5.2  Tool  Manaf^ement.  With  regard  to  networking  for  tool  management,  the  suc- 
cessfiil  tool  management  system  has  the  correct  tool  available  for  the  operator  when  it  is 
required.  To  accomplish  this  goal,  Texas  Instruments  (TI)  is  creating  a  distributed  net¬ 
work  of  tooling  databases  that  supports  methods  and  tooling,  inventory  control,  purchas¬ 
ing,  incoming  inspection,  and  tool  regrinding.  The  network  links  several  manufacturing 
sites  located  throughout  northern  Texas  and  Colorado  providing  central  coordination  for 
cutting-tool  management.  Previously,  each  site  maintained  its  own  tool  database.  In  addi¬ 
tion,  TI  developed  a  central  database  providing  all  worldwide  TI  locations  real-time  access 
to  TI  failure  analysis  data.  The  Failure  Analysis  Database  (FADE)  is  one  of  many  central 
databases  available  through  TI's  global  network.  Centrally  located  in  Dallas,  Texas,  with 
remote  access  to  all  TI  locations,  FADE  can  be  accessed  from  any  TI  facility  in  the  world. 
AH  data  are  continually  online  and  updated  in  real  time. 

Texas  Instruments,  Dallas,  TX 

10.6.5.3  Data  Integration  in  an  Nondevelopmental  Item  (NDD  FacUity.  The  Sacramento 
Manufacturing  and  Services  Division  (SMSD)  NDI  facility  was  established  to  perform 
nondestructive  inspection  of  intact  aircraft,  aircraft  components,  and  other  items  requning 
inspection  such  as  antenna  components  and  structural  members.  The  items  are  mspected 
for  flaws,  anomalies,  defects,  corrosion,  Foreign  Object  Damage  (FOD),  and  repair  areas. 
The  inspection  data  on  a  particular  item  is  electronically  captured  as  images,  waveforms, 
and  other  data.  The  data  is  then  converted  to  a  simple  visual  format  and  delivered  with  the 
item  to  the  repair  shop.  Until  recently  these  individual,  independent  inspections  have  been 
analyzed  separately  with  no  electronic  connection  between  the  systems.  Joint  Continuous 
Acquisition  and  Life-Cycle  Support  (CALS)  technology  and  numerous  networked  high- 
powered  computers  have  enabled  overlaying  the  data  between  the  SMSD  inspection  sys¬ 
tems. 

Sacramento  Manufacturing  and  Services  Division.,  Sacramento,  CA 

10.6.6  Utilization  of  Optical  Memory  Cards  to  Enhance  Total  Asset  Tracking  and 
Visibility 

The  Army  and  the  Defense  Logistics  Agency  are  using  optical  memory  cards  to  track  as¬ 
sets  through  the  supply  chain  from  the  wholesale  level  to  the  retail  level. 

CASCOM,  Ft.  Lee,  VA 


10.6.7  Online  Spares  Acquisitioning 

McDonnell  Douglas  Aerospace  (MDA)  (St.  Louis)  has  developed  an  online  spare  parts  requi¬ 
sitioning  capability  that  enables  customers  to  access  and  order  spare  parts  automatically 
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through  the  use  of  Electronic  Data  Interchange  (EDI).  Initial  operations  address  Spare 
Part  Order  Administration  and  EDI  transactions  for  request  for  quote  (840)  and  response 
(843)  and  are  currently  operational  with  the  Navy's  Aviation  Supply  Office.  Although  the 
present  process  for  online  requisitioning  is  a  mixture  of  both  manual  and  automated  meth¬ 
ods,  these  improvements  have  greatly  reduced  requisition  time  from  several  months  to 
several  days.  MDA's  (St.  Louis)  benchmarking  results  in  this  area  indicate  that  it  can  ex¬ 
pect  further  unprovements  and  by  fuUy  automating  the  process,  reach  a  cycle  time  of 
about  two  hours. 

McDonnell  Douglas  Aerospace,  St.  Louis,  MO 

10.6.8  Use  of  a  specialized  Integrated  Product  Team  (IPT)  with  a  mission  to  tackle 
reduction  of  operating  and  maintenance  costs  through  a  series  of  compatible  actions 

French  engine  manufacturer,  SNECMA 


10.6.9  Enhanced  Reliability  Through  Advanced  Electronic  Cooling  System 

In  support  of  the  Standard  Hardware  Acquisition  and  Reliability  Program,  the  Crane  Site 
—  Naval  Surface  Warfare  Center  (NSWC)  undertook  a  project  to  design  and  demonstrate 
a  lightweight  military  avionics  electronics  enclosure  called  the  Advanced  Electronics 
Cooling  System  (AECS).  The  AECS  is  capable  of  effectively  dissipating  thermal  power 
almost  five  times  more  dense  than  in  existing  configurations  using  Format  E  Standard 
Electronic  Modules  (SEM-E)  to  meet  projected  requirements  for  the  year  2000  and  be¬ 
yond. 

Crane  Division,  Naval  Surface  Warfare  Center,  Crane,  IN 

10.6.10  Reliability  Modeling  Program 

Litton  DSD  Product  Effectiveness  Department  has  implemented  an  active  Reliability 
Modeling  Program.  Key  elements  of  this  program  are  the  Parts  Stress  Reliability  Predic¬ 
tions  (PRED)  and  the  Reliability,  Maintainability,  and  Availability  (RMA)  Modeling  pro¬ 
grams. 

Litton  Data  Systems  Division,  Agoura  Hills,  CA 


10.6.11  Modular  Design 

At  Litton  Amecom,  software  engineers  are  involved  from  the  beginning  of  system  devel¬ 
opment;  thus  they  can  provide  input  to  developing  the  software  requirements  for  the  sys¬ 
tem.  This  assures  that  the  software  requirement  specifications  are  complete  and  can  be 
implemented.  Advanced  tools  are  used  for  software  development.  One  of  the  most  pow¬ 
erful  of  these  is  an  online,  structured  method  for  developing  system  software  design  re¬ 
quirements.  It  is  a  commercial  program  produced  by  Yourdon,  Incorporated,  called  Your- 
don  Engineering  Workbench,  which  runs  on  a  PC.  The  structured  analysis  serves  as  an 
organizing  tool  for  the  designer.  It  enables  linkage  between  system  requirements  and  de¬ 
sign  and  assures  complete  and  nonredundant  designs.  The  program  facilitates  rapid  system 
modeling  and  design  modeling  and  is  self-documenting.  It  provides  an  efficient  method  for 
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transferring  design  specifications  to  software  and  hardware  designers.  The  structured  ap¬ 
proach  encourages  software  component  modularity  for  off-the-shelf  availability.  They 
have  found  that  many  modules  can  be  used  in  other  applications,  which  reduces  develop¬ 
ment,  schedule,  cost,  and  performance  risk.  The  modeling  and  simulation  features  of  the 
program  allow  verification  of  algorithms,  subsystems,  and  system  designs.  It  can  also  be 
used  to  do  sensitivity  and  "what  if  analyses  and  to  establish  the  system  design-dependent 
mission  effectiveness. 

Litton  Amecom 


10.6.12  Standard  Interfaces 

Vetronics,  the  electronics  and  software  that  control  many  armored  vehicles  systems,  have 
become  more  numerous  and  complex.  United  Defense,  L.P.,  Ground  Systems  Division 
(GSD)  determined  that  it  needed  better  methods  to  control  how  these  systems  interacted. 
The  basic  problems  centered  on  vehicle  operators  attempting  to  manage  the  individual 
vetronic  systems  interaction.  New  procedures  were  developed  to  guide  the  vetronies  de¬ 
velopment  and  integration  process.  The  strategy  was  to  keep  the  designs  modular  and  ge¬ 
neric,  and  to  maximize  their  potential  for  reuse.  This  strategy  was  earned  out  by  using 
standard  military  and  commercial  interface  specifications,  whenever  possible,  as  well  as  by 
using  an  object-oriented  design  approach. 

United  Defense,  L.P.,  Ground  Systems  Division,  Santa  Clara,  CA 

10.6.13  Online  Logistics  Support  Database 

The  logistics  support  data  is  derived  fi-om  the  same  database  used  by  design  and  test  engi¬ 
neering.  The  ITT  Avionics  Division  has  implemented  an  online  logistics-support  database 
that  can  be  accessed  by  manufacturing,  design,  and  logistics  groups. 

ITT  Avionics  Division,  Clifton,  NJ 

10.6.14  Interactive  Computer-Aided  Provisioning  System 

Phalanx  provisioning  data  was  originally  manually  prepared  by  the  ISEA/Design  Agency 
and  manually  input  into  the  ship's  provisioning  system  by  the  Inventory  Control  Point 
(ICP)  provisioner  at  the  Louisville  site  of  NSWC.  Hard  copies  were  transmitted  back  and 
forth  until  all  data  and  fields  were  validated.  Louisville  has  implemented  the  Interactive 
Computer-Aided  Provisioning  System  (ICAPS)  to  automate  Phalanx  techmeal  doeumen- 

tation  development  and  submission. 

Crane  Division,  Naval  Surface  Warfare  Center,  Crane,  IN 

10.6.15  Continuous  Acquisition  and  Life-Cycle  Support  (CALS) 

Lockheed  Martin  and  AT&T  Federal  Systems  Advanced  Technology  have  applied  the 
CALS  concepts  in  differing  fashions  as  described  in  the  following  subsections. 
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0.6.15.1  Lockheed  Martin.  Laboratory  systems  engineering  and  laboratory  testing  have 
been  applied  to  CALS  candidate  products  at  Lockheed  Martin-Government  Electronics 
Systems  (LM-GES)  since  1994.  The  CALS  goal  of  a  Contractor's  Integrated  Technical 
Information  Service  has  been  promoted  since  the  mid  1980s,  but  implementations  have 
been  scarce.  LM-GES  established  a  laboratory  to  provide  a  test-bed  for  products  deter¬ 
mined  to  provide  CALS-compliant  solutions  to  various  requirements.  Testing  is  being 
performed  in  the  context  of  a  nine-step,  systems  engineering,  life-cycle  process  focused  on 
CALS-defined  inputs  and  outputs. 

Lockheed  Martin,  Government  Electronic  Systems,  Moorestown,  NJ 

10-615.2  AT&T  Federal  Systems  Advanced  Technology  IFSATV  The  Computer-Aided 
Acquisition  and  Logistics  Support  Development  group  has  adopted:  (1)  an  integrated  ap¬ 
proach  including  Total  Quality  Management  (TQM)  for  continuous  process  improvement, 
(2)  CALS  for  automation  of  technical  data,  and  (3)  electronic  data  interchange  for  auto¬ 
mation  of  business  transactions.  Applying  this  integrated  approach  has  resulted  in  a  pa¬ 
perless  environment  with  reduced  costs,  lead  times,  and  improved  quality.  Metrics  for  cost 
reduction,  cycle-time  reduction,  and  the  reduction  of  the  number  of  iterations  per  illustra¬ 
tion  have  been  developed  as  well  as  an  increased  percentage  of  graphics  images  used.  For 
example,  this  initiative  has  a  projected  savings  of  over  $3  million  for  production  of  docu¬ 
mentation.  These  figures  are  based  on  the  number  of  dehvered  master  pages  per  year  of 
documentation. 

AT&T  Federal  Systems  Advanced  Technology,  and 
BeU  Labs  (Lucent  Technology),  Greensboro,  NC 

10.6.16  ISO  9000  Certified  Suppliers 

Lockheed  Martin  Electronics  and  Missiles  has  instituted  a  conpany-wide  best  practices  pro¬ 
gram  that  focuses  on  the  quality  of  the  process  as  well  as  the  product.  The  approach  provides 
broad  coverage  of  representative  Department  of  Defense  and  other  customer  thrusts  such  as 
the  Army's  Contractor  Performance  Certification  Program  (CP)2,  the  Air  Force's  Manufactur¬ 
ing  Development  Initiative,  ISO  9000,  and  agile  manufacturing.  It  incorporates  them  into  12 
best  practices,  each  of  the  best  practices  is  clearly  defined  and  supported  by  a  vice-president- 
level  executive  advocate  and  a  management  inplementation  team. 

Lockheed  Martin  Electronics  and  Missiles,  Orlando,  FL 

10.6.17  POC/Reference 

Best  Manufacturing  Practices  Program,  4321  Hartwick  Rd.,  Suite  400,  College 
Park,  MD  20740;  telephone:  1-800-789-4267;  FAX:  301-403-8180;  Internet 
address:  http://www.bmpcoe.org 

Automated  Lessons  Learned  CoUection  and  Retrieval  System  (ALLCARS), 

Internet  address:  http://www.afam. wpafb.afmil/LL_Web/allcars.htm 
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11 

LOGISTICS  TEST  AND  EVALUATION 


Logistics  Test  And  Evaluation  Extends  Over  The  Entire  Acquisition 
Cycle,  And  Includes  Development  Test  &  Evaluation  (DT&E),  Opera¬ 
tional  Test  &  Evaluation  (OT&E),  And  Supportability  Assessments. 

Truism 


11.1  POT  JCY  AND  OBJECTIVES 

11.1.1  DoD  5000.2-R  PoUcy 

Test  and  evaluation  (T&E)  planning  (including  logistics  T&E  planning)  begins  at  Phase 
0,  Concept  Exploration.  Test  and  evaluation  planning  addresses  Measures  of  Effective¬ 
ness  (MOEs)  and  Measures  of  Suitability  (MOSs)  with  appropriate  quantitative  criteria. 
These  criteria  include  test  event  or  scenario  descriptions,  resource  requirements  (e.g., 
special  instrumentation,  test  articles,  vahdated  threat  targets,  vahdated  threat  simulators 
and  vahdated  threat  simulations,  acmal  threat  systems  or  surrogates,  and  personnel),  and 
test  hmitation  identification. 

Accredited  modeUng  and  simulation  is  apphed,  as  appropriate,  throughout  the  system  life 
cycle  in  support  of  the  various  acquisition  activities,  including  requirements  definition 
and  logistics  support.  Program  Managers  (PMs)  integrate  the  use  of  modehng  and 
simulation  within  program  planning  activities;  plan  for  Ufe-cycle  apphcation,  support, 
and  reuse  of  models  and  simulations;  and  integrate  modehng  and  simulation  across  the 
functional  disciphnes. 

The  Test  and  Evaluation  Master  Plan  (TEMP)  focuses  on  the  overaU  structure,  major 
elements,  and  objectives  of  the  test  and  evaluation  program  that  are  consistent  with  the 
acquisition  strategy.  It  should  include  sufficient  detail  to  ensure  the  timely  availabihty  of 
both  existing  and  planned  test  resources  requirements  to  support  the  test  and  evaluation 
program. 

A  TEMP  shall: 

•  be  prepared  for  ah  Acquisition  Category  (ACAT)  I  and  ACAT  LA  programs 
and  other  acquisition  programs  designated  for  the  Director,  Operational  Test 
and  Evaluation  (DOT&E),  Office  of  the  Secretary  of  Defense  (OSD),  or 
OSD’s  test  and  evaluation  oversight  (10  USC  §2399); 

•  be  approved  by  the  DOT&E  and  the  Director,  Test,  Systems  Engineering,  and 
Evaluation  (DTSE&E);  and 
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•  provide  a  road  map  for  integrated  simulation,  test  and  evaluation  plans, 
schedules,  and  resource  requirements  necessary  to  accomplish  the  test  ^d 
evaluation  program. 

The  TEMP  format  and  procedures  are  provided  in  Appendix  ffl  of  DoD  5000.2-R.  This 
format  may  be  used  at  the  discretion  of  the  Milestone  Decision  Authority  (MDA)  for 
other  ACAT  H  and  El  programs  and  for  highly  sensitive  classified  programs. 

Logistics  T&E  Objectives 

The  overall  objectives  of  logistics  T&E  are: 

•  to  provide  assurance  of  system  supportabihty  under  anticipated  wartime  con¬ 
ditions; 

•  to  verify  that  the  logistics  support  planned  and  developed  for  the  system  is  ca¬ 
pable  of  achieving  established  system  readiness  levels  within  the  established 
life-cycle  cost  thresholds;  and 

•  to  demonstrate  that  system  readiness  objectives  are  attained  at  peacetime  utili¬ 
zation  rates. 

11.2  MANAGEMENT  TSSTTF.S 

Logistics  test  and  evaluation  extends  over  the  entire  acquisition  cycle;  and  it  includes 
Development  Test  &  Evaluation  (DT&E),  Operational  Test  &  Evaluation  (OT&E),  and 
supportabihty  assessments.  The  Logistics  Manager  (LM)  must  be  a  participant  in  the  Test 
and  Evaluation  Integrated  Product  Team  (T&E  IPT)  planning  of  DT&E  and  OT&E  and 
IS  directly  responsible  for  the  planning  of  postdeployment  supportabihty  assessments. 

An  integrated  database  of  ah  data  from  Developmental  Testing/Operational  Testing 
pT/OT)  logistics  evaluations  provides  larger  sample  sizes  that  are  needed  for  confidence 
in  the  vahdity  of  test  results  and  as  an  aid  to  minimize  redundant  testing. 

11.2.1  Development  Test  and  Evaluation  (DT&E) 

DT&E  is  part  of  the  engineering  design  and  development  process.  It  verifies  the  attain¬ 
ment  of  technical  performance  specification  thresholds  and  objectives.  Figure  11-1  iden¬ 
tifies  the  T&E  objectives  of  major  interest  to  the  LM.  The  tests  are  conducted  generally 
by  the  prime  contractor  and  developing  agency  and  under  conditions  that  are  not  fully 
representative  of  field  operation. 
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11^.2  Operational  Test  and  Evaluation  (OT&E) 

OT&E  is  conducted  to  assess  a  system's  operational  effectiveness  and  suitability,  includ¬ 
ing  the  adequacy  of  the  system’s  logistics  support  (Figure  11-1)  during  pre-Milestone 
(MS)  in  phases  of  development.  The  tests  or  assessments  are  normally  conducted  and 
data  is  normally  evaluated  by  an  independent  field  agency  that  is  separate  from  the  de¬ 
veloper  and  user.  Initial  Operational  Test  and  Evaluation  is  performed  in  an  environment 
as  operationally  realistic  as  possible.  A  complete  evaluation  of  the  system's  supportabil- 
ity  design  parameters  (e.g.,  operational  R&M)  and  the  logistics  elements  should  be  con¬ 
ducted  during  the  Engineering  and  Manufacturing  Development  (EMD)  phase,  and 
should  employ  production  representative  systems. 


ACQWSmON 
N.  PHASE 

TEST  N. 

TYPE  N. 

CX>NCEPT 

EXPLORATION 

&DERNiTK>N 

PROGRAM 
DEFINITION  AND 
RISK 

REDUCTION 

ENGINEERING  & 
MANUFACTURING 

DEVELOPMENT 

PRODUCTION, 

RELDING/DEPLOYHENT 

AND  OPERATIONAL 
SUPPORT 

DEVELOPMENT 

T&E 

^Select 

Prefenwl 
System  and 
Support 
Concepts 

•  Identify 

Preferred 

Technical 

Approach, 

L^istlc  Risks, 
and  Preferred 
Solutions 

•  Identify  Design  Problems  and  Solutions 
Including: 

—Survivability 

—Compatibility 

—Transportation 

-R&M 

-Safety 

—Human  Factors 

•  Ensure  Production  Items  Meet 
Design  Requirements  and 
Spedfications 

•  Ensure  Adequacy  of  System 
Design  Changes 

OPERATIONAL 
T&E  AND 
SUPPORTABIUTY 
ASSESSMENT 

•  Assess 
Operattonal 
Impact  of 
Candidate 
Technical 
Approaches 

•  Assist  In 
Selecting 
Prsferred 
System  and 
Support 
Concepts 

•  Estimate 
Operational 
Compatibility 
and  Suitability 

•  Examine 
Operational 

Aspects  of 
Attemative 
Technical 
Approaches 

•  Estimate  Potential 
Operational 
SuHablittyof 
Candidate 

Systems 

•  Assess  Operational  Suitability 
—Operational  R&M 
-Built-In  Diagnostic  Capability 
— ‘Dansportabllity 

•  Evaluate  Logistics  Supportability 
—Effectiveness  of  Maintenance  Ptanning 
—Appropriate  Personnel  Skills/Grades 
—Appropriate  Spares,  Repair  Parts,  Bulk 

Supplies 

—Adequate  Support  Equipment,  Including 
Effective  ATE  and  Software 
—Accurate  and  Effective  Technical  Data; 
VaUdation/Vbrification  of  Technical 

Manuals 

—Adequate  Facilities  (Space,  Environmental 
Systems,  Storage) 

—Effective  Packaging,  Ufilng  Devices,  Tie- 
Down  Points,  'nanspoilatlon  Instructions 

•  Ensure  Production  Items 

Meet  Operational  SultabUlty 
Requirements 

•  Demonstrate  Attainment  of 
System  Readiness 

Objectives 

•  Update  O&S  Cost  Estimates 

•  Evaluate  Ooerational 

Suitability  and  Supportability 
of  Design  Changes 

•  Identify  Improvement 

Required  in  Supportability 
Parameters 

•  Provide  Data  Required  to 

Adjust  ILS  Elements 

Figure  11-1:  Logistics  Objectives  in  the  T&E  Program 


This  evaluation  may  continue  into  the  next  phase  with  pilot  or  full-rate  production  items. 
All  logisties  elements  should  be  provided  in  a  condition  or  configuration  that  is  close  to 
or  identical  to  the  one  provided  after  deployment.  As  a  minimum,  the  operational  test 
environment  should  include: 

•  representative  military  operation  and  maintenance  personnel; 

•  trained  personnel,  using  a  prototype  of  the  planned  formal  training  program; 
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draft  technical  manuals; 


•  production  representative  systems; 

•  support  equipment  selected  for  operational  use;  and 

•  realistic  tactical  environment. 

11^.3  Supportability  Assessment 

A  supportability  assessment  is  performed  in  two  general  stages:  (1)  assessment  as  part  of 
the  formal  DT&E  and  OT&E  programs  and  (2)  assessment  performed  after  deployment 
through  analysis  of  operational,  maintenance,  and  supply  data  on  the  system  in  its  opera¬ 
tional  environment.  Participating  with  the  project  office  T&E  IPX  in  the  planning  of 
DT&E  and  OT&E  programs,  the  LM  develops  detailed  logistics  T&E  objectives  for  each 
acquisition  phase  and  incorporates  these  objectives  into  the  formal  test  programs. 

Assessments  of  some  logistics  elements  may  require  additional  or  separate  tests.  Two 
common  examples  are  validating  the  accuracy  of  technical  manuals  and  demonstrating 
maintainability  to  evaluate  maintenance  activities.  These  are  generally  initiated  prior  to 
the  formal  test  programs  in  order  to  reduce  delays  during  testing.  The  evaluation  of  lo¬ 
gistics  elements  is  discussed  in  1 1.2.4  below.  The  LM  is  responsible  for  the  planning  of 
postdeployment  supportability  assessments.  General  objectives  are  listed  in  Figure  11-1. 
The  planning  should  identify  the  following  items: 

•  objectives  and  specific  planned  uses  of  the  assessment  analyses  and  reports; 

•  specific  parameters  to  be  estimated  (e.g.,  operational  availability.  Operations 
and  Support  (O&S)  costs,  maintenance  replacement  rates  for  spares  and  repair 
parts,  and  operational  reliability  and  maintainability); 

•  data  sources  and  methods  of  collection; 

•  statistical  validity  required; 

•  duration  of  data  collection; 

•  data  analysis  methods  and  reports;  and 

•  plaimed  utilization  of  the  assessment  reports. 
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11^.4  Evaluation  of  logistics  elements 

The  eight  logistics  elements  listed  below  should  be  evaluated  individually  to  determine 
the  impact  of  that  element  on  system  readiness  and  system  ownership  costs.  The  T&E 
IPT  is  faced  with  the  same  scheduling  challenge  in  this  regard  as  with  all  testing  during 
system  development.  Appropriate  tests  and  evaluations  should  be  accomplished  as  early 
as  feasible  to  bring  problem  areas  to  light  and  resolve  them.  On  the  other  hand,  most 
testing  and  evaluation  should  be  conducted  on  production  representative  items  to  bring 
confidence  and  vahdity  to  the  test  results.  As  a  practical  matter,  the  majority  of  the  lo¬ 
gistics  T&E  will  take  place  in  the  latter  stages  of  EMD  or  in  the  early  stages  of  the  Pro¬ 
duction,  Fielding/Deployment,  and  Opertional  Support  phase,  when  the  logistics  ele¬ 
ments  are  available.  Refer  to  Figure  11-1. 

1 1 .2.4. 1  Mainfpnanrp.  Planning  This  element  is  evaluated  to  verify  proper  assignment 
of  maintenance  tasks  to  maintenance  levels  and  the  appropriate  selection  of  support 
equipment  and  personnel  to  perform  maintenance  tasks.  A  structured  maintainability 
demonstration  is  an  effective  evaluation  mechanism;  at  a  minimum,  the  demonstration 
should  include  all  organizational  and  selected  intermediate  level  tasks. 

11.2.4.2  Manpower  and  Personnel.  Training,  and  Training  Support.  These  factors  are 
tested  and  evaluated  to  ensure  that: 

•  the  number  of  personnel  and  the  skills  they  will  need  to  support  a  system  in  its  op¬ 
erational  environment  are  identified; 

•  the  effectiveness  of  the  government  personnel  training  program,  as  reflected  in 
their  abihty  to  operate,  support,  and  maintain  the  materiel  system  under  test,  is  as¬ 
sessed;  and 

•  training  devices  are  provided  in  the  proper  quantities  and  at  functional  areas. 

1 1 .2.4.3  Supply  Support.  This  element  is  evaluated  to  verify  that  the  quantities  and 
types  of  items  and  suppUes  designed  to  maintain  the  system  in  its  prescribed  state  of  op¬ 
erational  readiness  are  adequate.  Both  peacetime  and  wartime  usage  rates  should  be 
evaluated. 

1 1. 2.4.4  Support  Equipment.  This  element  is  evaluated  to  determine  its  effectiveness, 
the  vahdity  of  the  planned  requirements,  and  the  progress  achieved  toward  meeting  those 
requirements.  Test  and  evaluation  should  verify  that  all  items  function  as  required  and 
that  no  requirement  exists  for  items  not  Usted.  Compatibihty,  integration,  and  inter- 
operabihty  are  significant  evaluation  issues. 

1 1 .2.4.5  Technical  Data.  The  data  are  tested  and  evaluated  to  assure  that  they  are  accu¬ 
rate,  understandable,  and  complete,  as  well  as  able  to  satisfy  maintenance  requirements  at 
projected  skill  levels. 
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Computer  Resources  Support.  This  element  supports  both  embedded  com¬ 
puter  systems  and  the  automatic  test  equipment  that  provide  support  for  the  end  item.  In 
general,  evaluation  of  this  area  addresses  the  adequacy  of  the  hardware  and  the  accuracy, 
documentation,  and  maintenance  of  computer  software  routines.  Built-in  test  routines 
programmed  into  the  software  of  a  complex  device,  such  as  a  computerized  aircraft  fire- 
control  system,  would  be  covered  in  this  area  of  the  evaluation. 

1 1 .2.4.7  Facihties.  Facilities  are  evaluated  to  determine  whether  the  following  areas 
have  been  defined  and  satisfied: 

•  facihties  requirements  in  terms  of  space,  volume,  capital  equipment,  and  utihties 
necessary  for  system  operation  and  maintenance;  and 

•  environmental  system  requirements  (for  example,  temperature,  humidity,  and  dust 
control)  associated  with  operations,  maintenance,  and  storage  facihties. 

1 1 .2.4. 8  Packaging,  Handhng,  Storage,  and  Transportability.  These  evaluations  wiU 
determine  whether: 

•  provided  transportabihty  instructions  are  adequate; 


•  conventional  types  of  lifting,  loading,  and  handhng  equipment  can  handle  the  system; 

•  hfting  and  tie-down  points  conform  to  appropriate  size,  strength,  and  markings 
standards; 

•  the  system  is  adaptable  to  prescribed  forms  of  transport  (surface,  sea,  and  air,  as 
apphcable); 

•  the  equipment  and  personnel  can  be  moved  with  ease  from  the  ships  to  shore  as¬ 
sembly  points  in  logistic-over-the-shore  operations;  and 

•  transport  and  storage-handling  damages  are  limited  effectively  by  packaging. 

11*3  TESTING  COMMERCIAL/NDT  ITEMS 

The  incorporation  of  commercial  or  Nondevelopmental  Items  (NDI)  into  DoD  systems 
poses  special  T&E  challenges.  The  contractor  T&E  data  should  be  thoroughly  reviewed. 
As  appropriate,  an  additional,  tailored  T&E  program  should  be  developed  and  executed 
to  provide  data  not  available  from  the  contractor’s  program  and  to  reflect  the  environ¬ 
ment  and  operating  demands  of  the  system  under  development. 
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11.4  STATISTICAL  VALIDITY 


There  is  a  tradeoff  among  the  numbers  of  test  hours  that  can  be  expended,  the  failure 
rates  experienced  during  the  testing,  and  the  degree  of  precision  that  statistical  analyses 
permit  us  to  glean  from  those  tests.  In  practice,  test  hours  are  limited  by  funds  available 
for  testing,  the  numbers  of  items  available  for  test,  time  available  for  testing,  and  the  way 
in  which  failures  occur.  While  it  might  be  possible  to  exercise  some  control  over  fund¬ 
ing,  failure  rates  and  their  distribution  among  the  various  components  and  subsystems  are 
inherent  to  the  system’s  design  and  use.  Careful  attention  to  the  selection  of  statistical 
methodologies  is  important  for  both  development  and  operational  testing  of  the  logistics 
support  of  a  system. 
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PART  III 


LOGISTICS  RESOURCES  AND 

TOOLS 


12 

LOGISTICS  COST  ESTIMATING 


“Never  invest  your  money  in  anything  that  eats  or  needs  repairing. 

Billy  Rose 


12.1  POLICY 

On  15  March  1996,  the  Secretary  of  Defense  promulgated  the  latest  revision  to  the  DoD  5000 
series  acquisition  directives.  The  covering  memo  outhned  six  major  themes  contained  in  the  up¬ 
dated  documents.  One  of  those  major  themes  is  that,  “The  acquisition  process  must  consider 
both  performance  requirements  and  fiscal  constraints.  Accordingly,  cost  must  also  be  an  inde¬ 
pendent  variable  in  programmatic  decisions,  with  responsible  cost  objectives  set  for  each  pro¬ 
gram  phase.”  This  theme  is  to  be  known  as  Cost  As  an  Independent  Variable  (CAIV). 

Every  issuance  of  the  acquisition  policy  documents  has  emphasized  this  same  theme,  and  cor¬ 
rectly  so.  CAIV  is  the  latest  in  a  series  of  terms  intended  to  put  focus  on  life-cycle  cost.  Past  and 
current  initiatives  have  addressed  Should  Cost,  Budget  To  Cost,  and  Design  To  Cost  (DTC), 
with  variations  such  as  Design-to-unit  Production  Cost  (DTUPC)  and  Design  to  Life-cycle  Cost 
(DTLCC).  Additionally,  terms  such  as  Life-cycle  Cost  Procurement  (LCCP)  and  Life-cycle  Cost 
Management  (LCCM)  have  come  into  common  usage  as  cost  concepts  have  been  applied  in  an 
effort  to  comply  with  policy  documents.  The  current  DoD  5000.2-R  includes  Program  Acquisi¬ 
tion  Unit  Cost,  Average  Procurement  Unit  Cost  (undefined),  and  Average  Unit  Procurement 
Cost. 

To  understand  what  is  new  about  Life-cycle  Cost  (LCC),  review  the  way  it  is  woven  into  the 
policy  directives  and  consider  the  concept  in  the  context  of  the  overall  agenda  of  acquisition  re¬ 
form  in  the  mid  1990’ s.  By  1991,  when  the  policy  directives  were  last  updated,  LCC  was 
strongly  encouraged  and  described  on  about  20  of  the  900  pages  in  the  policy  directives.  How¬ 
ever,  in  1991  LCC  and  DTC  were  encouraged  but  optional  at  all  levels  of  acquisition  program 
decision  making.  When  the  policy  documents  were  overhauled  for  the  1996  issuance,  the  overaU 
page  count  decreased  to  less  than  100  pages;  and  LCC,  under  its  new  title  CAIV,  was  mentioned 
approximately  25  times  thoughout  the  documents.  Clearly,  the  relative  importance  of  LCC 
greatly  increased;  and,  more  importantly,  it  is  now  mandatory  for  the  major  acquisition  category 
programs. 

Many  contemporary  political  issues  dictate  that  control  of  the  costs  associated  with  both  acquisi¬ 
tion  and  ownership  of  weapons  systems  receive  an  unprecedented  level  of  management  attention. 
On  4  December  1995,  the  Under  Secretary  of  Defense  for  Acquisition  and  Technology  issued  a 
memorandum  on  the  subject  of,  “Reducing  Life-Cycle  Costs  for  New  and  Fielded  Systems.” 

The  memorandum  started  with  the  statement  that,  “Reducing  the  cost  to  acquire  and  operate  the 
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department’s  equipment  while  maintaining  a  high  level  of  performance  for  the  user  is  my  highest 
priority.” 

Some  readers  may  ask  if  this  is  just  the  same  concept  as  the  old  5000-series  directives,  which  are 
described  as  “Design-To-Cost.”  In  fact,  the  concept  is  the  same,  and  the  LCC  analysis  process  is 
the  same.  But  the  emphasis  and  environment  are  different.  What  was  optional  in  the  old  LCC 
directives  is  now  mandatory,  and  a  fundamental  change  has  occurred  in  DoD-level  acquisition 
strategy.  For  more  than  30  years,  DoD  acquisitions  were  reactions  to  a  constantly  changing  So¬ 
viet  technological  threat.  To  counter  this  threat  DoD  acquisitions  experienced  an  evolving  set  of 
requirements  because  of  the  length  of  the  acquisition  hfe  cycle,  changes  in  the  enemy’s  capabili¬ 
ties,  and  emerging  technological  opportunities.  These  factors  regularly  resulted  in  programs  that 
experienced  significant  cost  growth  and  the  accompanying  negative  reactions  of  those  who  did 
not  understand  the  reasons  for  the  growth.  Added  to  this  is  a  current  perception  that  some  por¬ 
tion  of  the  changes  and  cost  growth  was  unwarranted.  This  has  been  referred  to  as  the  1 10  per¬ 
cent  solution  to  a  requirement.  Various  contractor  and  program  staff  members  were  adding 
“bells  and  whistles”  on  systems  to  the  point  where  “gold  plating”  was  not  unusual.  In  hindsight, 
it  appears  that  serious  discussions  between  the  developer  and  the  user,  with  a  view  toward  hold¬ 
ing  cost  growth  down,  did  not  always  take  place.  CAIV  is  a  change  to  the  former  trend.  CAIV 
and  LCC  are  hkely  to  be  much  more  of  a  cost-holding  force  for  many  socioeconomic  reasons, 
including  peace  dividend  mentality,  user  paying  the  support  bill  within  Defense  Working  Capital 
Fund  (DWCF),  sustainment  bill  taking  all  of  the  budget  (proportionally  few  defense  dollars 
available  for  modernization),  etc. 

The  objectives  of  CAIV  follow: 

•  setting  realistic  but  aggressive  cost  objectives  early  in  each  acquisition  program, 

•  devising  and  employing  a  process  for  accomplishing  cost-schedule-performance 
tradeoffs  during  each  acquisition  phase  and  at  each  milestone  decision  point, 

•  managing  risks  to  achieve  cost,  schedule,  and  performance  objectives, 

•  devising  appropriate  metrics  for  tracking  progress  in  setting  and  achieving  cost 
objectives, 

•  motivating  government  and  industry  managers  to  achieve  program  objectives,  and 

•  establishing  in-place  additional  incentives  to  reduce  operating  and  support  costs  for  fielded 
systems. 

The  challenge  to  the  acquisition  logistician  is  to  champion  the  implementation  of  these  concepts 
actively  and  aggressively  through  participation  in  the  various  Integrated  Process  Teams  (IPTs). 
Knowledgeable  use  of  Life-cycle  Costing  can  be  the  catalyst  in  assuring  affordabihty  of  systems 
when  fielded  for  operations  by  the  user. 
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12.2  LIFE-CYCLE  COST  (LCC)  OVERVIEW 


The  life  cycle  of  a  system  begins  with  the  determination  of  a  mission  requirement  and  includes 
research  and  development  (R&D),  production,  deployment,  operation,  support,  and  eventual  dis¬ 
posal  or  demilitarization  by  the  Department  of  Defense  (DoD).  Program  phases  may  overlap 
considerably;  in  particular,  R&D  may  not  be  completed  before  procurement  begins. 

12.2.1  LCC  Analysis  Is  an  Iterative  Process 

The  LCC  estimate  must  reflect  program  changes  as  they  occur.  LCC  Management  (LCCM)  is 
the  program  office  disciphne  used  to  incorporate  LCC  in  program  office  decision  making.  The 
lead  acquisition  logistics  manager  will  generally  be  tasked  to  provide  Operating  and  Support 
(O&S)  cost  support  for  the  LCC  estimate. 

12.2.1.1  LCC  Breakdown.  For  purposes  of  cost  estimating,  LCC  is  typically  divided  into  re¬ 
search  and  development,  procurement,  O&S,  and  disposal.  The  following  descriptions  provide  a 
brief  summary  of  the  costs  associated  with  each  hfe-cycle  phase  (see  Figure  12-1): 

•  R&D.  R&D  consists  of  those  costs  incurred  from  program  initiation  at  the  concep¬ 
tual  phase  through  the  end  of  engineering  and  manufacturing  development.  R&D 
costs  include  the  cost  for  feasibility  studies,  modehng,  tradeoff  analyses,  engineering 
design,  development,  fabrication,  assembly  and  test  of  prototype  hardware  and  soft¬ 
ware,  system  test  and  evaluation,  associated  peculiar  support  equipment,  and  docu¬ 
mentation. 

•  Procurement.  Procurement  includes  the  costs  associated  with  producing  or  procuring 
the  prime  hardware,  support  equipment,  training,  data,  initial  spares,  and  facilities. 


Figure  12-1:  Growth  in  Weapon  System  Life-Cycle  Cost 
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•  O&S.  O&S  consists  of  all  costs  incurred  by  the  DoD  to  field/deploy  the  system  in¬ 
cluding  personnel,  consumable  and  reparable  parts,  fuel,  shipping,  and  maintenance. 

•  Disposal.  Disposal  captures  costs  associated  with  deactivating  or  disposing  of  a 
materiel  system  at  the  end  of  its  useful  life.  Disposing  of  a  materiel  system  can  re¬ 
sult  in  additional  costs  or  a  salvage  value  depen^ng  on  the  disposition.  This  cost  is 
normally  insignificant  compared  to  the  total  LCC.  The  main  exceptions  to  this  in¬ 
clude  disposal  of  nuclear  waste,  missile  propellants,  and  other  materials  requiring 
expensive  detoxification  or  special  handling. 

12.2.1.2  Design  to  Cost  (PTC)  Establishes  LCC  as  a  Design  Parameter.  DTC  requires  the  es- 
tabhshment  of  cost  goals  and  strives  to  incorporate  these  goals  into  the  system  design.  Initial 
DTC  activity  focuses  on  identifying  system  cost  drivers,  potential  risk  areas,  and  cost/schedule/ 
performance  tradeoffs.  As  development  continues,  efforts  focus  on  identifying  areas  requiring 
corrective  actions.  Cost  reduction  techniques  are  apphed  to  such  areas  to  keep  costs  within  an 
acceptable  range. 

12.2.1.3  Depth  and  Aecuracy  of  Estimates.  The  depth  and  accuracy  of  cost  estimates  depend  on 
the  acquisition  program  phase  and  the  use  of  the  estimate.  At  Milestone  1,  veiy  httle  will  be 
known  about  the  detailed  design  of  the  proposed  system.  However,  affordabihty  of  the  program 
must  be  evaluated,  alternatives  compared,  and  DTC  goals  estabhshed.  The  most  significant  im¬ 
pact  on  costs  can  be  achieved  prior  to  Milestone  I.  This  is  when  major  decisions,  such  as  the 
selection  of  a  manned  vs.  an  unmaimed  system  are  made.  Such  decisions  lock  in  major  costs  for 
the  system.  The  opportunity  to  influence  cost  diminishes  as  the  program  matures.  See  Figure 
12-2  and  Figure  12-3. 


Figure  12-2:  Entire  Acquisition  Time  Line 
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Figure  12-3:  Early  Impact  of  Decisions  on  Life-Cycle  Cost 


123  OPERATIONS  &  SUPPORT  (O&S)  COST  OVERVIEW 

O&S  costs  are  those  incurred  by  the  DoD  for  the  peacetime  operations  and  maintenance  of  a 
system  throughout  its  life  cycle.  Major  determinants  of  0«&:S  costs  are  design  characteristics, 
reliability,  maintainabiUty,  and  mission  requirements. 

123.1  Uses  of  O&S  Cost  Information 

O&S  cost  information  is  used  for  a  variety  of  purposes  throughout  the  acquisition  process,  in¬ 
cluding  the  following: 

•  support  of  the  design-to-cost  program, 

•  support  of  milestone  decisions, 

•  discrimination  among  alternative  designs, 

•  support  of  budget  estimates,  and 

•  conducting  Tradeoff  Analysis. 

12.33  Depth  and  Accuracy  of  Estimates 

As  part  of  LCC  estimating,  the  detail  and  accuracy  of  the  O&S  cost  estimate  also  depends  on  the 
acquisition  program  phase  at  the  time  the  estimate  is  initiated/revised/completed  and  the  in¬ 
tended  use  of  the  O&S  estimate.  As  a  system  is  developed  and  designs  and  support  concepts  are 
evolved,  O&S  cost  estimates  and  cost  comparisons  should  become  increasingly  accurate.  By 
Milestone  n,  the  subsystem  O&S  cost  drivers  should  be  identified.  Cost  drivers  are  characteris- 
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tics  of  a  system  or  subsystem  that  influence  a  major  share  of  the  system  cost.  An  understanding 
of  the  system's  design  is  neeessary  for  identification  of  system  cost  drivers. 

The  O&S  cost  estimates  prepared  for  Milestone  HI  are  based  on  system  design  characteristics, 
deployment  schedule,  and  operation  and  maintenance  concepts.  Operating  experience  obtained 
during  system  test  and  evaluation  is  used  to  verify  progress  in  meeting  O&S  cost  goals  and  to 
identify  problem  areas. 

1233  Summary  of  the  LCC  Analysis  Process 
The  analysis  process  follows  these  steps; 

•  defining  the  problem  (the  requirement  for  the  analysis); 

•  analyzing  the  goals  of  the  analysis; 

•  selecting  the  elements  of  cost  to  include  in  the  analysis  and  select  or  construct  a  model; 

•  collecting  required  model  input  data; 

•  runing  the  model,  including  “what-ifs”  and  sensitivities; 

•  performing  analysis  of  model  output  data  and  developing  conclusions;  and 

•  documenting  the  analysis  results  and  making  reeommendations. 

12.4  O&S  COST  METHODOLOGY 

Before  initiating  an  O&S  cost  estimate,  the  methodology  for  the  estimate  must  be  determined. 
This  methodology  will  depend  on  the  purpose  of  the  estimate,  the  system  under  analysis,  the  ac¬ 
quisition  phase,  and  the  data  available.  Using  this  information,  a  procedure  for  accomphshing 
an  estimate  could  begin  by: 

•  estabhshing  a  set  of  study  objectives; 

•  determining  the  O&S  cost  of  similar  systems  and  budgeted  or  programmed  O&S  costs 
of  the  new  system. 

•  reviewing,  if  apphcable  and  available,  the  Analysis  of  Alternatives;  and 

•  performing  a  “should  cost”  or  cost  reduction  exercise. 
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12.4.1  Develop  Ground  Rules,  Facts  Bearing  on  the  Problem,  and  Assumptions 

Ground  rules,  facts  bearing  on  the  problem,  and  assumptions  (where  needed  facts  are  not  avail¬ 
able)  are  based  on  the  way  the  system  will  be  operated,  maintained,  and  supported  in  peacetime. 
The  ground  rules,  facts,  and  assumptions  include  descriptions  of  relevant  missions  and  system 
characteristics  and  manning,  maintenance,  support,  and  logistics  policies.  All  ground  rules, 
facts,  and  assumptions  must  be  clearly  stated  and  documented. 

The  intended  use  of  the  system  should  be  determined  in  order  to  identify  the  pertinent  support 
characteristics;  planned  logistics  resources;  and,  in  turn,  the  related  cost.  As  stated  in  the 
USAMC  Logistic  Support  Activity  prepared  DoD  Handbook:  Acquisition  Logistics  (MIL- 
HDBK-502),  “Determining  the  best  set  of  planned  logistics  resources  for  a  system  is  the  function 
of  the  acquisition  logistics  discipline  of  systems  engineering.  It  is  accomphshed  through  analysis 
of  those  design  characteristics,  which  generate  a  need  for,  or  are  associated  with,  providing  op¬ 
erational  support  to  the  total  system.  These  design  characteristics  are  developed  by  many  differ¬ 
ent  disciplines  pursuing  a  wide  range  of  systems  engineering  activities.  Individually  they  may  be 
viewed  as  hardware,  software,  or  support-system  design  characteristics.  Collectively  they  repre¬ 
sent  the  “supportability”  of  a  total  system.”  For  example,  in  estimating  O&S  cost  for  ground- 
based  radar  system  maintenance  requirements,  consideration  must  be  given  to  the  need  for  a  24- 
hour-a-day,  365-day-a-year  mission.  The  acquisition  logistics  discipline  of  systems  engineering 
would  likely  perform  tradeoff  analyses  between  system  redundancy  and  the  costs  of  maintenance 
manpower/spares  required  to  ensure  affordable  mission  availability  is  met.  The  O&S  cost  would 
be  developed  accordingly. 

12.4.2  Select  Comparable  System 


A  comparable  system  may  be  an  operational  program  with  a  mission  similar  to  the  proposed 
program.  It  is  often  the  system  being  replaced,  unless  another  system  provides  a  better  reference 
for  the  analysis.  There  are  a  variety  of  sources  within  each  Service  for  obtaining  technical,  per¬ 
formance,  and  cost  data  on  comparable  systems.  The  assumptions,  ground  rules,  and  cost  esti¬ 
mating  methodologies  for  both  the  comparable  and  proposed  systems  must  be  related.  This  is 
essential  in  order  to  identify  differences  in  resource  consumption  due  to  differences  in  system 
characteristics.  Caution  is  necessary  when  considering  data  from  a  system  acquired  prior  to  the 
implementation  of  Acquisition  Reform.  Comparable  system  data  are  then  adjusted  to  better  ap¬ 
proximate  the  proposed  system. 

12.4.3  Identify  O&S  Cost  Drivers 

System  O&S  cost  drivers  must  be  identified  early  in  the  system  life  cycle.  These  vary  from  pro¬ 
gram  to  program  but  are  defined  as  those  elements  in  the  program  that  have  a  major  impact  on 
system  LCC.  As  the  program  matures,  these  drivers  should  influence  system  design  choices.  As 
the  design  matures,  O&S  cost  drivers  will  change.  Alternative  approaches,  design  tradeoffs,  and 
sensitivity  of  O&S  costs  to  changes  should  be  evaluated  within  the  “Analysis  Of  Alternatives” 
(AOA). 
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12.5  DETERMINE  COST-ESTIMATING  TECHNIQUE 


When  estimating  the  O&S  cost  of  a  system,  there  are  several  techniques  that  may  be  applied. 

The  choice  of  technique  depends  on  the  maturity  of  the  program  and  the  data  available.  Most 
O&S  analyses  are  accomphshed  using  a  combination  of  three  estimating  techniques:  analogous 
system,  parametric,  and  engineering.  The  latter  is  sometimes  called  a  “bottoms  up”  or  “grass 
roots”  estimate  and  uses  accounting-type  data.  As  the  program  progresses  from  concept  devel¬ 
opment  to  production,  more-detailed  cost  data  become  available.  Initial  estimates  are  then  up¬ 
dated  with  a  prototype  test  or  acmal  operational  data.  Regardless  of  the  estimating  technique 
appUed,  appropriate  documentation  must  accompany  the  estimate.  The  following  is  a  summary 
of  each  of  these  estimating  techniques. 

12.5.1  Analogous  System 

In  this  technique,  a  currently  fielded  system  (a  comparable  system)  that  is  similar  in  design 
and/or  operation  to  the  proposed  system  is  identified.  Taking  the  fielded  system’s  data  and  ad¬ 
justing  them  to  account  for  any  differences  then  develops  the  cost  of  the  proposed  system.  The 
analogous  system  may  be  a  composite  of  several  fielded  systems.  This  technique  of  cost  estima¬ 
tion  is  widely  used.  One  drawback  to  analogous  system  estimation  is  the  amount  of  detailed 
technical  and  engineering  data  required.  The  analogous  system  approach  places  heavy  emphasis 
on  the  opinions  of  "experts."  Therefore,  it  is  necessary  to  document  clearly  the  rationale  used  to 
determine  the  composition  of  the  analogous  system  and  the  adjustment  factors  used. 

12.5.2  Parametric 

The  parametric  approach  employs  Cost-Estimating  Relationships  (CERs)  to  develop  estimates 
using  regression  analysis.  A  CER  is  an  equation  that  relates  one  or  more  characteristics  of  an 
item  to  some  element  of  its  cost.  For  example,  a  study  of  existing  avionics  equipment  may  yield 
a  CER  relating  avionics  unit  cost  to  the  weight  of  the  avionics  system.  This  CER  could  then  be 
used  to  predict  avionics  unit  cost  for  a  new  system,  which  has  weight  that  needs  estimated. 
Normally  analogy  or  parametric  estimating  is  used  early  in  the  Ufe  cycle  of  a  system,  when  item 
specific  data  is  not  known.  CERs  must  be  examined  to  ensure  they  are  current  (i.e.,  reflect  ac¬ 
quisition  reform),  appropriate  for  the  range  of  data  being  estimated,  and  applicable  to  the  sys¬ 
tem.  If  they  are  improperly  apphed,  the  result  could  be  serious  estimating  errors. 

12.5.3  Accounting  Estimates 

The  accounting  method  uses  engineering  estimates  of  reliability,  maintainabihty,  and  component 
cost  characteristics  (optempo  rates)  to  build  estimates  from  the  "bottom-up"  for  each  cost  cate¬ 
gory.  Accounting  estimates  require  detailed  system  data.  The  system  is  typically  broken  down 
into  lower-level  components,  and  estimates  of  each  component  are  made.  Although  this  method 
can  be  complex  and  time  consuming,  it  is  the  method  of  choice  when  detailed  system  data  is 
available. 
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12.6  SELECTING  THE  MOST  APPROPRIATE  COST  MODEL 


As  with  the  choice  of  methodology,  the  selection  of  an  O&S  cost  model  also  depends  on  the 
purpose  of  the  estimate,  the  system  under  analysis,  the  acquisition  phase,  and  (most  importantly) 
the  data  available. 

12.6.1  Desired  Characteristics 

Although  no  single  O&S  model  can  be  used  for  all  purposes,  an  O&S  model  should  have  as 
many  of  the  following  characteristics  as  possible: 

12.6. 1 . 1  Consistency.  A  consistent  model  conforms  to  current  O&S  cost-estimating  practices. 
This  allows  the  proposed  system  to  be  compared  to  an  analogous  system. 

12.6.1.2  Flexibihtv.  The  model  should  be  constructed  so  that  it  is  useful  in  the  early  phases  and 
can  evolve  to  acconunodate  more-detailed  information  as  the  program  continues  through  its  life 
cycle. 

12.6.1.3  Simplicity.  The  model  should  require  only  the  minimum  data  necessary  to  estimate  the 
O&S  cost.  More  complex  models  can  be  used  as  more  data  becomes  available. 

12.6.1.4  Usefulness.  The  model  should  provide  useful  information  to  the  decision  makers  in 
their  evaluation  of  support  and  design  tradeoffs. 

12.6.1.5  Completeness.  O&S  models  should  include  aU  apphcable  costs  for  a  system's  opera¬ 
tion  and  support  over  its  useful  life. 

12.6.1.6  Vahdity.  The  model  should  be  capable  of  providing  logical,  reproducible  results. 

12.6.2  Cost  Models  in  Wide  Use 

Three  O&S  cost  models  widely  used  in  the  DoD  are  the  Cost  Analysis  Strategy  Assessment 
(CASA)  model,  the  Air  Force’s  Cost-Oriented  Resources  Estimating  (CORE)  model,  and  the 
Logistics  Support  Costs  (LSC)  model.  A  sampling  of  models  selected  to  illustrate  the  charac¬ 
teristics  for  a  credible  O&S  cost  model  follows: 

12.6.2. 1  CASA.  CASA  is  designed  as  an  engineering  estimate  or  accounting  model.  No  CERs 
are  used.  The  model  conforms  to  the  requirements  of  the  Office  of  the  Secretary  of  Defense 
(OSD)  Cost  Analysis  Improvement  Group  (CAIG)  guidelines  for  cost  elements.  The  model  uses 
some  90  algorithms  and  190  variables  to  capture  all  relevant  operating  and  support  costs.  It  is 
flexible  which  means  most  of  the  inputs  are  optional  so  the  model’s  capability  can  be  tailored  to 
the  needs  of  the  LCC  analyst.  Also,  the  model  uses  fixed  formulas  so  the  analysis  is  completely 
repeatable.  It  is  general  purpose  and  has  been  used  in  all  of  the  Services  to  support  analysis 
needs  on  a  wide  variety  of  systems  and  equipment. 
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12.6.2.2  CORE.  CORE  is  designed  to  provide  a  cost-estimating  technique  to  be  used  to  develop 
aircraft  O&S  cost  estimates.  CORE  uses  data  available  from  standard  USAF  data  systems  (con¬ 
sistency).  It  allows  the  estimating  techniques  to  vary  as  the  program  progresses  through  the 
phases  of  acquisition  (flexibihty),  and  it  estimates  all  common  O&S  cost  elements  (complete¬ 
ness).  It  uses  the  format,  cost  element  structure,  and  procedures  generally  required  for  milestone 
briefings  (usefulness). 

12.6.2.3  LSC.  The  LSC  uses  consistent  data  for  comparable  systems  available  from  standard 
USAF  data  sources  (consistency)  and  also  contains  built  in  factors  allowing  the  model  to  be  used 
when  little  item-specific  data  is  available.  As  the  program  matures  and  item-specific  data 
evolves,  the  factors  are  replaced,  which  results  in  an  improved  O&S  cost  estimate  (flexibility). 
The  LSC  model  addresses  spares,  depot  maintenance,  and  transportation  in  detail.  Manpower, 
support  equipment,  and  training  are  addressed  only  superficially;  fuel  and  other  costs  of  opera¬ 
tion  are  not  included  in  the  model. 

12.7  DATA  SOURCES 

Various  sources  of  data  are  available  to  accomplish  O&S  cost  estimates.  As  with  budget  esti¬ 
mation,  which  is  normally  based  on  actual  contract  expenditures  on  similar  acquisitions,  O&S 
costs  come  from  the  reporting  of  information  from  field  use  of  similar  systems.  The  data  source 
will  depend  on  the  type  of  analysis  and  model  being  used.  With  the  advent  of  widespread  use  of 
LCC  in  the  early  1970s,  the  Navy  began  development  of  the  Visibihty  and  Management  of  Op¬ 
erating  and  Support  Costs  (VAMOSC)  data  reporting  system.  Over  the  years  VAMOSC  has 
been  underfunded  and  repeatedly  “re-engineered”  as  organizations  and  their  reporting  capability 
have  continually  come  and  gone.  Each  of  the  Services’  centers  for  cost  analysis  is  involved  in 
VAMOSC-associated  work.  In  mid- 1996  the  OSD  CAIG  and  the  Navy  Center  for  Cost  Analysis 
teamed  to  investigate,  once  again,  the  VAMOSC  for  a  major  re-engineering  in  support  of  the 
CATV  initiative.  Many  of  their  recommended  improvements  are  already  being  implemented. 

The  following  are  types  of  data  drawn  from  VAMOSC  and  other  Service  databases.  The  final 
paragraph  of  this  chapter  lists  each  Service  Component’s  cost  center. 

12.7.1  Comparable  System  Data 

Comparable  system  data  are  used  in  accomphshing  analysis  before  specific  system  details  are 
available.  The  logistics  manager  must  adjust  comparable  system  data  to  reflect  the  changes  ex¬ 
pected  in  the  proposed  system.  For  example,  if  the  proposed  system  incorporates  built-in  test 
(BIT)  while  the  comparable  system  does  not  have  this  capabiUty,  the  comparable  system  data  on 
fault  isolation  labor-hours  would  have  to  be  adjusted  to  reflect  BIT  use  in  the  proposed  system. 

12.7.2  Engineering  Estimates 

As  the  system  definition  matures,  system-specific  data  replaces  comparable  system  data.  System 
engineers  are  the  primary  source  for  item-specific  rehability  and  maintainability  data  plus  per¬ 
formance  estimates.  This  data  is  followed  by  test  and  evaluation  data  and  then  by  actual  field 
data. 
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12.73  Usage  Data 


The  program  will  need  to  make  provision  for  a  consistent  source  of  logistics  and  other  data  for 
O&S  cost  analyses.  The  program  analysis  database  should  include  specific  data  on  costs,  reli¬ 
ability,  maintainability,  training,  support  equipment,  provisioning,  packaging,  facilities,  etc.  The 
program  data  may  or  may  not  be  consistent  with  some  Service-specific  O&S  cost  models.  Some 
program  data  may  have  to  be  adjusted  to  account  for  model  definition  or  format  differences. 

12.7.4  Cost  and  Planning  Factors 

The  Military  Departments  maintain  cost  and  planning  factors,  which  can  be  used  to  estimate  re¬ 
source  requirements  and  costs  associated  with  force  structures,  missions,  and  activities. 

2.8  COMPLETING  THE  O&S  COST  ESTIMATE 


Once  the  technique,  model,  and  data  are  in  hand,  it  is  time  to  estimate  and  evaluate  the  relevant 
O&S  costs.  Applying  the  available  data  to  the  model  selected  generates  an  estimate.  The  accu¬ 
racy  of  an  O&S  cost  estimate  is  affected  by  uncertainties  from  many  sources.  It  is  important  to 
identify  and  bound  the  scope  of  variables  that  contribute  to  uncertainty.  Each  variable  should  be 
examined  independently,  and  cross-checks  should  be  performed  to  ensure  that  the  estimate  is 
credible. 

12.8.1  Sensitivity  Analysis 

To  identify  those  element  outputs  that  are  particularly  vulnerable  to  relatively  small  changes  in 
driver  input  values,  sensitivity  analysis  varies  the  data  inputs  of  certain  cost  drivers.  This  analy¬ 
sis  is  performed  to  identify  the  magnitude  of  the  uncertainty  in  the  O&S  cost  estimate  and  to 
identify  areas  that  require  further  management  attention.  Sensitivity  analysis  can  also  determine 
the  effects  of  data  uncertainties  and  changes  in  ground  rules  and  assumptions. 

12.8.2  Documenting  the  Results 

Detailed  documentation  of  the  cost  estimate  is  essential  to  an  O&S  estimate.  The  documentation 
serves  as  the  audit  trail  of  the  ground  rules,  facts  bearing  on  the  problem  and  assumptions,  esti¬ 
mating  techniques,  model  selection  basis,  data  sources,  sensitivity  analysis,  and  results.  The 
documentation  should  explain  the  methods  used  to  establish  the  bounds  and  the  elements  in¬ 
cluded  in  the  sensitivity  analysis.  The  documentation  provides  sufficient  information  for  the 
replication  and  confirmation  of  the  estimate  by  an  experienced  analyst. 

12.83  Making  Revisions 

The  O&S  cost  estimate  is  revised  prior  to  each  milestone  review  to  incorporate  all  changes  to  the 
program  since  the  last  milestone  or  revision.  Keeping  an  estimate  current  at  all  times  is  essen¬ 
tial.  Therefore,  as  major  program  changes  occur,  the  O&S  estimate  is  revised  (even  if  an  O&S 
cost  impact  is  not  readily  apparent).  For  example,  a  decision  to  change  to  composite  material 
may  result  in  less  maintenance  required  but  more  expensive  repair  techniques. 
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12.9  USES  FOR  THE  O&S  COST  ESTIMATE 


The  O&S  Cost  estimate  is  a  large  part  of  the  total  program  LCC.  O&S  cost  estimates  are  re¬ 
quired  whenever  the  LCC  estimate  is  prepared.  Annual  program  office  estimate  requirements 
vary,  but  usually  include  O&S  costs. 

12.9.1  Analysis  Of  Alternatives  (AOA) 

The  analysis  is  to  aid  decision  makers  in  judging  whether  or  not  any  of  the  proposed  alternatives 
to  an  existing  system  offer  sufficient  military  and/or  economic  benefit  to  be  cost  worthy. 

12.9.2  Tradeoffs 

Once  a  baseline  estimate  is  complete,  the  impact  of  program  changes  on  O&S  costs  can  be 
evaluated.  When  combined  with  schedule  and  performance  data  and  an  objective  function,  the 
estimate  may  support  a  CATV-based  tradeoff  exercise.  An  example  of  a  design  tradeoff  is  an 
Engineering  Change  Proposal  (ECP).  The  ECP  analysis  is  used  to  assess  the  cost  imphcations  of 
a  proposed  design  change.  The  decision  to  accept  or  reject  the  ECP  is  made  after  considering 
the  effect  on  program  costs.  Comparing  the  cost  of  the  basehne  configuration  with  the  cost  of 
the  proposed  configuration  assesses  the  ECP.  Areas  of  uncertainty  are  identified  and  appropriate 
sensitivity  analyses  performed. 

12.9.3  Independent  Cost  Estimate  (ICE) 

An  ICE  is  a  cost  estimate  prepared  by  an  objective  nonprogram  office  team.  The  decision  mak¬ 
ers  use  the  ICE  primarily  to  identify  any  inconsistencies  with  the  program  office  estimate.  An 
O&S  cost  estimate  is  a  major  portion  of  these  ICE  efforts. 

12.9.4  Milestone  Reviews 

During  a  milestone  review,  program  LCC  is  carefully  scrutinized  to  determine  program  readi¬ 
ness  to  proceed  to  the  next  acquisition  phase.  Both  the  program  office  estimate  and  the  ICE  are 
reviewed  to  determine  if  the  program  is  still  likely  to  meet  requirements  and  is  still  cost- 
effective.  A  recommendation  is  provided  to  the  decision  makers  following  this  review. 

12.9.5  Source  Selection 

O&S  estimates  should  be  an  integral  part  of  the  most  probable  cost  for  each  proposal  under  con¬ 
sideration  during  source  selection.  These  most  probable  costs  are  used  by  the  source  selection 
authority  in  award. 
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12.9.6  Budgeting 

Budgeting  for  O&S  cost  elements  is  one  use  of  the  estimate.  The  current  DoD  trend  is  to  track 
cost  estimating  more  closely  with  budgeting.  An  effort  is  underway  to  incorporate  the  O&S  cost 
estimate  into  die  Acquisition  Program  Baseline  (APB). 

12.10  REFERENCES 

1.  “Acquisition  Logistics,”  Department  of  Defense  Handbook  (MIL-HDBK-502),  pre¬ 
pared  by  USAMC  Logistic  Support  Activity,  ATTN:  AMXLS-ALD,  Building  5307, 
Redstone  Arsenal,  AL  35898-7466.  WEB:  http://www.logsa.army.niil: 80/logsa.htm 

2.  Service  Cost  Centers: 

Army 

U.S.  Army  Cost  and  Economic  Analysis  Center 

5611  Columbia  Pike 

Falls  Church,  Virginia  22041 

Tel:  DSN  761-3336/7/8;  Comm  (703)  681-3336/7/8 

E-Mail:  TRMATEER@aol.com 

WEB:  http://www.asafm.army.mil 

Navy 

Navy  Center  for  Cost  Analysis 
1 1 1 1  Jefferson  Davis  Highway 
Arlington,  Virginia  22202-4306 
TEL:  Comm  (703)  604-0293 
E-Mail:  downsirene@ncca.navy.mil 
WEB:  www.ncca.navy.mil/ncca.htm 

Air  Force 

Air  Force  Cost  Analysis  Agency 

1 1 1 1  Jefferson  Davis  Highway 

Arlington,  Virginia  22202 

TEL:  Comm  (703)  604-0387 

E-Mail:  WEEKS@afcaanet.afcaapo.hqaf.mil 

WEB:  http://www.saffm.hq.af.mil/SAFTM/ 
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13 

LIFE-CYCLE  COST  (LCC) 

“A5  to  government  expenditures,  those  due  to  broken-down  chariots,  worn- 
out  horses,  armor  and  helmets,  arrows  and  crossbows,  lances,  hand  and 
body  shields,  draft  animals  and  supply  wagons  will  amount  to  60  percent  of 
the  total.  ” 

Sun  Tzu,  The  Art  of  War  (Sixth  century  B.C.) 


13.1  POLICY 

13.1.1  Broad  Policy 

Defense  acquisition  policy,  as  stated  in  DoDD  5000.1,  includes  the  requirement  to  obtain  quality 
products,  at  a  fair  and  reasonable  price.”  This  directive,  which  governs  the  defense  acquisi¬ 
tion  system,  goes  on  to  address  cost  and  life-cycle  costs  in  each  of  the  three  major  policy  areas. 
Requirements  include  the  need  to: 

•  minimize  the  cost  of  ownership  in  the  context  of  a  total  system  approach; 

•  view  cost  in  the  context  of  Cost  As  an  Independent  Variable  (CAIV),  recognizing  that 
the  majority  of  costs  are  determined  e^ly  in  a  program; 

•  work  closely  with  the  user  to  achieve  a  proper  balance  among  cost,  schedule,  and  per¬ 
formance  while  ensuring  that  systems  are  both  affordable  and  cost-effective. 

The  Program  Manager  (PM),  together  with  the  user,  are  to  propose  cost  objectives  and  thresholds 
for  Milestone  Decision  Authority  (MDA)  approval,  which  will  then  be  controlled  through  the 
Acquisition  Program  Baseline  (APB)  process.  Further,  the  PM  is  asked  to  search  continually  for 
innovative  practices  to  reduce  costs,  including  prudent  investments  in  pollution  prevention  in  an 
effort  to  reduce  life-cycle  environmental  costs  and  Uability.  Finally,  the  acquisition  community 
is  to  recognize  that  competition  provides  major  incentives  for  industry  to  enhance  the  application 
of  advanced  technology  and  life-cycle  cost  advantages  to  defense  programs  as  well  as  a  mecha¬ 
nism  to  obtain  an  advantageous  price. 

13.1.2  DoD  5000.2-R  Policy 

For  all  Acquisition  Category  (ACAT)  I  and  lA  programs,  a  life-cycle  cost  estimate  shall  be  pre¬ 
pared  by  the  program  office  in  support  of  program  initiation  (usually  Milestone  I)  and  all  subse¬ 
quent  milestone  reviews.  The  Component’s  staffing  authority  shall  prepare  a  staffing  estimate 
for  ACAT  I  programs  in  support  of  Milestone  II  and  Milestone  III.  For  ACAT  I  programs,  the 
MDA  may  not  approve  entry  into  engineering  and  manufacturing  development  or  production  and 
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deployment  unless  an  independent  estimate  of  the  full  life-cycle  cost  of  the  program  and  a  staff¬ 
ing  estimate  for  the  program  have  been  completed  and  considered  by  the  MDA  (10  USC  §2434). 

The  life-cycle  cost  estimates  shall  be: 

•  explicitly  based  on  the  program  objectives,  operational  requirements,  contract  specifica¬ 
tions  for  the  system,  and  (for  AC  AT  I  programs)  a  life-cycle  cost  and  benefit  element 
structure  agreed  upon  by  the  Integrated  Product  Team  (IPT); 

•  comprehensive  in  character,  identifying  all  elements  of  cost  that  would  be  entailed  by  a 
decision  to  proceed  with  development,  production,  and  operation  of  the  system  regardless 
of  funding  source  or  management  control; 

•  for  ACAT I  programs,  consistent  with  the  cost  estimates  used  in  the  analysis  of  alterna¬ 
tives  and  for  staffing  estimates  behind  the  operation  and  support  costs,  consistent  with  the 
(Component’s)  staffing  estimate. 

•  Neither  optimistic  nor  pessimistic  but  based  on  a  careful  assessment  of  risks  and  reflect¬ 
ing  a  realistic  appraisal  of  the  level  of  cost  most  Ukely  to  be  realized. 

For  ACAT  I  programs,  the  DoD  Component  sponsoring  the  acquisition  program  shall  estabUsh, 
as  a  basis  for  the  life-cycle  cost  estimates,  a  description  of  the  salient  features  of  the  acquisition 
program  and  of  the  system  itself.  This  description,  referred  to  here  as  a  Cost  Analysis  Require¬ 
ments  Description  (CARD),  is  given  to  the  teams  preparing  the  program  office  life-cycle  esti¬ 
mate,  Component  cost  analysis,  and  independent  life-cycle  cost  estimate.  The  description  should 
be  prepared  180  days  in  advance  of  a  planned  Overarching  Integrated  Product  Team  (OIPT)  or 
Component  review,  unless  another  due  date  is  set  by  the  OIPT.  The  CARD  shall  be  flexible, 
tailored,  and  make  reference  to  information  available  in  other  documents  available  to  the  cost 
estimators.  For  joint  programs,  the  CARD  shall  include  the  conunon  program  as  agreed  to  by 
participating  DoD  Components.  For  ACAT  lA  programs,  the  PM  shall  prepare  the  CARD  in 
coordination  with  the  appropriate  IPT  members. 

For  programs  with  significant  cost  risk  or  high  visibility,  the  Component  Acquisition  Executive 
(CAE)  may  request  that  a  component  cost  analysis  estimate  also  be  prepared  in  addition  to  the 
program  office  hfe-cycle  cost  estimate.  For  all  ACAT  I  programs,  the  Office  of  the  Secretary  of 
Defense  (OSD)  Cost  Analysis  Improvement  Group  (CAIG)  shall  prepare  an  independent  hfe- 
cycle  cost  estimate  and  a  report  for  the  appropriate  MDA  for  all  milestone  reviews  after 
Milestone  0. 

For  all  ACAT  lA  programs,  the  Office  of  Secretary  of  Defense  (OSD)  Principal  Staff  Assistant 
(PSA)  or  sponsoring  DoD  Component  shall  ensure  that  a  Component  cost  analysis  is  created  for 
Milestone  I  and  updated  for  Milestone  II.  The  MDA  may  direct  an  updated  analysis  for  subse¬ 
quent  decision  points  if  conditions  warrant.  At  Milestone  I,  the  component  may  conduct  a  suffi¬ 
ciency  review  of  the  PM’s  life-eycle  cost  estimate  in  lieu  of  a  full  analysis.  The  IPT  shall  estab¬ 
lish  the  content  of  sufficiency  review. 
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13.2  USES  OF  LIFE-CYLE  COST 


The  LCC  estimate  plays  a  key  role  in  the  management  of  an  acquisition  program.  Its  primary 
functions  include  providing  the  following  information: 

•  major  input  to  acquisition  decisions  among  competing  major  system  alternatives; 

•  input  in  requirements  determination;  and 

•  within  a  selected  system  alternative 

—  identification  of  cost  drivers, 

—  index  of  merit  for  tradeoff  evaluations  in  design,  logistics,  and  manufacturing,  and 

—  the  basis  for  overall  cost  control. 

13.3  MILESTONE  DECISION  POINTS  AND  COST 

Upon  approval  of  a  Mission  Need  Statement  (MNS),  an  approach  shall  be  formulated  to  set  and 
refine  cost  objectives.  By  program  initiation  (usually  Milestone  I),  each  ACAT I  and  ACAT  lA 
PM  shall  have  established  life-cycle  cost  objectives  for  the  program  through  consideration  of 
projected  out-year  resources,  recent  unit  costs,  parametric  estimates,  mission  effectiveness  analy¬ 
sis  and  trades,  and  technology  trends.  A  complete  set  of  life-cycle  cost  objectives  shall  include 
Research,  Development,  Test,  and  Evaluation  (RDT&E),  production,  operating  and  support,  and 
disposal  costs.  At  each  subsequent  milestone  review,  cost  objectives  and  progress  towards 
achieving  them  shall  be  reassessed. 

At  each  milestone  decision  point,  including  the  decision  to  start  a  new  program,  life-cycle  costs, 
cost/performance/schedule  tradeoffs,  cost  drivers,  and  affordability  constraints  will  be  among  the 
major  considerations. 

13.4  COST  CONTENT  WITHIN  THE  ACQUISITION  PROGRAM  BASELINE 

The  cost  parameters  stated  in  the  APB  shall  be  limited  to  these  costs: 

•  RDT&E  costs, 

•  procurement  costs, 

•  military  construction  costs, 

•  costs  of  acquisition  items  procured  with  Operations  and  Maintenance  (O&M)  funds, 
if  applicable, 

•  total  quantity  (to  include  both  fully  configured  development  and  production  units). 
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•  average  unit  procurement  cost  (defined  as  the  total  procurement  cost  divided  by  total 
procurement  quantity), 

•  program  acquisition  unit  cost  (defined  as  the  total  of  all  acquisition  related  appropria¬ 
tions  divided  by  the  total  quantity  of  fully  configured  end  items),  and 

•  any  other  cost  objectives  designated  by  the  MDA,  e.g.,  life-cycle  cost  objective. 

All  estimates  are  to  be  expressed  in  base-year  dollars.  As  the  program  progresses  through  later 
acquisition  phases,  procurement  costs  shall  be  refined  based  on  contractor  actual  costs  from  pro¬ 
gram  definition  and  risk  reduction,  engineering  and  manufacturing  development,  or  from  initial 
production  lots.  The  amount  budgeted  shall  not  exceed  the  total  cost  threshold  estimated  in  the 
APB.  For  AC  AT  lA  programs,  the  AC  AT  I  cost  parameters  apply,  with  the  addition  of  military 
pay  and  Defense  Working  Capital  Fund  (DWCF). 

No  funds  shall  be  obhgated  for  an  AC  AT  I  program  after  that  program  enters  the  Engineering 
and  Manufacturing  Development  (EMD)  phase  or  production  and  deployment  until  an  APB  has 
been  approved  by  the  MDA,  unless  the  USD(A&T)  has  specifically  approved  the  obligation  (10 
U.S.C.  §2435(b)4). 

13.5  COST/PERFORMANCE  TRADEOFFS 

The  best  time  to  reduce  life-cycle  costs  is  early  in  the  acquisition  process.  Cost  reductions  are 
accomplished  through  cost/performance  tradeoff  analyses,  which  are  conducted  before  an  acqui¬ 
sition  approach  is  finalized.  To  facilitate  that  process,  the  Overarching  IPT  (OIPT)  for  each 
ACAT I  and  ACAT  lA  (as  required)  program  establishes  a  Cost  Performance  IPT  (CPIPT).  The 
user  community  is  represented  on  the  CPIPT.  Industry  representation,  consistent  with  statute  and 
at  the  appropriate  time,  is  also  considered. 

Maximizing  the  PM’s  and  contractors’  flexibility  to  make  cost/performance  tradeoffs  without 
unnecessary  higher-level  permission  is  essential  to  achieving  cost  objectives.  Therefore,  the 
number  of  threshold  items  in  requirements  documents  and  acquisition  program  baselines  are 
strictly  limited;  the  threshold  values  represent  true  minimums;  and  requirements  are  stated  in 
terms  of  performance  rather  than  technical  solutions  and  specifications.  The  systems  engineering 
process,  system  analysis,  and  control  are  established  to  serve  as  a  basis  for  evaluating  and  se¬ 
lecting  alternatives,  measuring  progress,  and  documenting  design  decisions.  This  includes  the 
conduct  of  tradeoff  studies  among  requirements  (operational,  functional  and  performance),  de¬ 
sign  alternatives  and  their  related  manufacturing,  testing  and  support  processes,  program  sched¬ 
ule,  and  life-cycle  cost.  These  tradeoff  studies  should  be  performed  at  the  appropriate  level  of 
detail  to  support  decision-making  and  lead  to  a  proper  balance  between  performance  and  cost. 
Request  For  Proposals  (RFPs)  include  a  strict  minimum  number  of  Key  Performance  Parameters 
that  will  allow  industry  maximum  flexibility  to  meet  overall  program  objectives.  Cost  objec¬ 
tives  are  used  as  a  management  tool.  The  source  selection  criteria  communicated  to  industry 
should  reflect  the  importance  of  developing  a  system  that  can  achieve  stated  production  and 
life-cycle  cost  thresholds. 
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13.6  COST  MANAGEMENT  INCENTIVES 


Incentives  shall  be  applied  to  both  government  and  industry  to  achieve  the  objectives  of  CAIV. 
Awards  programs  (both  monetary  and  nonmonetary)  and  "shared  savings"  programs  are  used 
creatively  to  encourage  the  generation  of  cost-saving  ideas  for  all  phases  of  life-cycle  costs.  In¬ 
centive  programs  target  both  individuals  and  teams  in  both  government  and  industry.  Incentives 
include  up-front  investments  to  minimize  production  and/or  operation  and  support  costs,  where 
applicable. 

13.7  ACQUISITION  LOGISTICS  COST 

Acquisition  programs  establish  logistics  support  concepts,  e.g.,  two-level  and  three-level,  early  in 
the  program  and  refine  them  throughout  the  development  process.  Life-cycle  costs  play  a  key 
role  in  the  overall  selection  process.  Support  concepts  for  new  and  future  systems  provide  for 
cost-effective,  total  life-cycle  logistics  support. 

The  PM  ensures  that  reliabiUty,  maintainability,  and  availability  activities  are  established  early  in 
the  acquisition  cycle  so  that  operational  requirements  and  reduced  life-cycle  ownership  cost  are 
met.  Reliability,  maintainability,  and  availability  requirements  are  based  on  operational  require¬ 
ments  and  Ufe-cycle  cost  considerations.  The  requirements  and  considerations  are  stated  in 
quantifiable,  operational  terms  that  are  measurable  during  developmental  and  operational  test 
and  evaluation  and  defined  for  all  elements  of  the  system,  including  support  and  training  equip¬ 
ment.  Figure  13-1  shows  the  dominant  role  that  logistics  plays  in  system  life-cycle  cost. 

13.8  THE  DEFENSE  WORKING  CAPITAL  FUND  (DWCF)^ 

As  a  revolving-fund  financial  structure,  the  DWCF  builds  on  revolving-fund  principles  previ¬ 
ously  used  for  industrial  and  commercial-type  operations.  The  DWCF  consists  of  multiple  divi¬ 
sions  identified  by  Component  and  by  business  area.  Within  these  business  areas,  there  are  sup¬ 
port  organizations  (providers)  which  operate  like  commercial  businesses  by  selling  goods  and 
services  to  DoD’s  operating  forces  and  other  business  areas  (customers). 

Customer  orders  (funded  requests  for  goods  and  service)  provide  the  budgetary  resources  to  fi¬ 
nance  defense  business  operations.  Customers  fund  their  requests  primarily  with  appropriated 
resources  (e.g.,  operation  and  maintenance;  procurement;  and  research,  development,  test,  and 
evaluation).  Income  (or  budgetary  resources)  derived  form  the  sale  of  goods  and  services  is  then 
used  to  finance  the  DWCF  business  areas’  continuing  operations  without  fiscal  year  limitations. 
Unlike  profit-oriented  commercial  businesses,  DWCF  businesses  strive  to  reach  break-even 
prices  charged  to  customers.  Revenue  from  customers  sustains  the  full  cost  and  the  continuous 
cycle  of  DWCF  business  operations. 


'  Reference  for  this  paragraph  is  as  follows:  Defense  Working  Capital  Fund  (DWCF)  Handbook,  CALIBRE  Systems,  Inc.,  Falls  Church,  Vir¬ 
ginia,  and  Office  of  the  Under  Secretary  of  Defense  (Comptroller),  Washington,  DC,  1995,  pp.  1-2  to  1-4. 
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Figure  13-1:  Nominal  Cost  Distribution 


The  basic  tenet  of  the  DWCF  financial  structure  is  to  create  a  customer-provider  relationship 
between  military  operating  forces  and  support  organizations. 

•  Customers  of  the  DWCF  business  area  providers  include  any  DoD  command  or  or¬ 
ganization,  non-DoD  Federal  Government  agencies,  and  other  U.S.  and  foreign  agen¬ 
cies  and  commercial  enterprises  when  authorized  by  DoD. 

•  Providers  in  the  DWCF  customer-provider  relationship  are  the  business  areas  and  re¬ 
lated  support  organizations  that  are  responsible  for  providing  goods  and  services  to 
the  operating  forces  and  that  are  financed  through  the  DWCF. 

The  customer-provider  relationship  is  fundamental  to  the  DWCF  financial  structure.  The  rela¬ 
tionship  has  significantly  increased  the  customer’s  responsibihty  for  properly  determining  sup¬ 
port  requirements  and  the  level  of  performance  required  from  DWCF-fmanced  support  organiza¬ 
tions.  The  result  of  the  customer-provider  relationship  is  a  meaningful  “linkage”  between  mili¬ 
tary  mission  operations  and  the  cost  to  support  those  operations. 

This  hnkage  is  a  major  feature  of  the  DWCF’s  control  process.  The  inclusion  of  previously  di¬ 
rectly  financed  areas  in  the  DWCF  is  causing  the  DWCF  business  area  operations  to  be  finan¬ 
cially  sized  (in  both  budget  and  implementation)  based  on  their  customers’  requirements  and  ap¬ 
propriated  resources  available  for  DWCF  goods  and  services.  In  other  words,  the  resources  re¬ 
quired  by  the  DWCF  business  area  organizations  to  continue  operations  vary  directly  with  their 
customers’  needs  for  their  goods  and  services.  As  the  volume  of  customer  requirements  decline. 
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so,  too,  will  the  relative  financing  of  a  supporting  DWCF  business  area.  The  significance  of  this 
linkage  makes  it  essential  for  customers  and  providers  alike  to  understand  the  nature  of  the 
DWCF  financial  processes  and  the  potential  impact  they  can  have  on  military  readiness. 

In  summary,  the  DWCF  financial  structure  and  management  processes  focus  on  total-cost  visi- 
biUty  and  full-cost  recovery  for  the  Department’s  support  functions.  The  DWCF  financial 
structure  provides  DoD  managers  with  improved  financial  management  tools  and  facilitates  the 
reduction  of  DoD  support  costs  through  better  business  practices.  The  use  of  the  DWCF  finan¬ 
cial  structure  is  intended  to; 

•  foster  a  business-like  customer-provider  approach  that  enables  the  customer  to  make 
economical  buying  decisions  and  encourages  the  provider  to  become  more  cost  con¬ 
scious; 

•  identify  the  full  costs  of  support,  measure  performance  on  the  basis  of  cost/output 
goals,  and  foster  efficiency  and  productivity  improvements; 

•  provide  timely  and  accurate  information  to  decision  makers  at  all  levels  to  enhance 
the  decision  making  process;  and 

•  more  closely  relate  the  support  infrastrueture  with  the  force  structure. 
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14 

COST  AS  AN  INDEPENDENT 
VARIABLE  (CAIV) 

“War  is  not,  as  some  seem  to  suppose,  a  mere  game  of  chance.  Its  principles  con¬ 
stitute  one  of  the  most  intricate  of  modem  sciences.  ” 

General  Henry  W.  Halleck, 

Elements  of  Military  Art  and  Science,  Third  ed.  (1863) 


14.1  POLICY 

The  acquisition  strategy  shall  address  methodologies  to  acquire  and  operate  affor^ble 
DoD  systems  by  setting  aggressive,  achievable  cost  objectives  and  managing  achieve¬ 
ment  of  these  objectives.  Cost  objectives  shall  be  set  to  balance  mission  needs  with  pro¬ 
jected  out-year  resources,  taking  into  account  anticipated  process  improvements  in  both 
DoD  and  defense  industries. 

14.1.1  Cost/Performance  Tradeoffs 

Cost  reductions  are  accomplished  through  cost/performance  tradeoff  analyses,  which 
shall  be  conducted  before  an  acquisition  approach  is  finalized.  To  facilitate  that  process, 
the  Overarching  Integrated  Product  Team  (OIPT)  for  each  Acquisition  Category  (ACAT) 
I  and  lA  (as  required)  program  estabUshes  a  Cost/Performance  IPT  (CPIPT).  The  user 
community  is  represented  on  the  CPIPT.  Industry  representation,  consistent  with  statute 
and  at  the  appropriate  time,  is  also  considered. 

14.2  COST  AS  AN  INDEPENDENT  VARIABLE  (CAIV) 

14.2.1  Discussion 


An  initiative  to  reduce  hfe-cycle  costs  of  systems  is  called  Cost  As  an  Independent  Vari¬ 
able  (CAIV).  Thus,  performance  and  schedule  are  a  function  of  available  (budgeted)  re¬ 
sources.  CAIV  was  proposed  in  1995  and  implemented  in  March  of  1996  as  part  of  the 
5000-series  directives  on  defense  weapons  systems  acquisition.  Implementation  is  di¬ 
rected  for  all  Major  Defense  Acquisition  Programs  (MDAPs)  in  Concept  Development  or 
Program  Definition  and  Risk  Reduction  phases  and  selected  programs  beyond  that  point. 
The  CAIV  concepts  will  be  of  value  to  all  acquisition  programs  and  has  particular  appli¬ 
cation  to  logistics  as  a  major  driver  of  life-cycle  costs. 

Two  DoD  working  groups  have  led  the  definition  and  implementation  of  CATV.  A  De¬ 
fense  Manufacturing  Council  (DMC)  Working  Group  developed  a  CATV  working  group 
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report  disseminated  in  December  1995,  which  describes  a  strategy  for  setting  aggressive, 
reahstic  cost  objectives  for  acquiring  defense  systems  and  managing  the  associated  risks. 
In  June  1996,  the  Flagship  Programs  Workshops  began  meeting  under  the  leadership  of 
the  Office  of  the  Under  Secretary  of  Defense  (Acquisition  and  Technology)  (OUSD 
(A&T)).  The  participants  include  representatives  of  eight  defense  programs  as  well  as 
representatives  of  the  Office  of  the  Secretary  of  Defense  (OSD),  Institute  for  Defense 
Analyses  (IDA),  and  the  Defense  Systems  Management  College  (DSMC). 

Continuing  this  momentum  in  1997,  a  DMC  planning  team  recommended  that  the  old 
council  be  sustained  under  a  new  name,  the  Defense  Systems  Affordabihty  Council 
(DSAC).  Under  this  new  name,  DMC  work  was  continued,  but  with  a  new  organization 
and  a  new  mode  of  operation.  DSAC’s  two  major  thrusts  were  to  (1)  continue  DMC 
momentum  on  ongoing  acquisition  reform  initiatives  including  CAIV  and  (2)  conduct  an 
integrated  acquisition  logistics  attack  on  life-cycle  cost.  The  first  DSAC  meeting  was 
held  2  June  1997. 

Figure  14-1  provides  a  listing  of  the  eight  flagship  programs.  Those  eight  programs  were 
(1996/97)  sharing  problems  and  solutions  in  implementing  CAIV  policy.  This  section 
looks  at  the  definitions,  concepts,  processes,  and  risks  of  CATV  with  examples  from  the 
Flagship  Programs. 

14.2.1.1  Definition.  CAIV  is  a  new  (1995)  DoD  strategy  that  makes  total  hfe-cycle  cost, 
as  projected  within  the  new  acquisition  environment,  a  key  driver  of  system  require¬ 
ments,  performance  characteristics,  and  schedules.  This  is  a  180-degree  conceptual 
change  in  thinking  from  the  days  of  requirements,  performance,  and  sometimes  schedule¬ 
driving  eosts.  While  the  hfe-cycle  cost/performance/requirements  tradeoff  process  is  the 
heart  of  CAIV,  a  broader  definition  is  necessary  to  recognize  the  environment  in  which 
these  trades  take  place.  Programs  are  being  aggressively  managed  to  meet  program  ob¬ 
jectives  concomitantly  with  the  implementation  of  reform  initiatives  such  as  use  of  com¬ 
mercial  specifications  and  practices.  Integrated  Product  and  Process  Development  (IPPD) 
Teams,  and  contractor  enterprise  re-engineering.  The  acquisition  reform  initiatives  have 
the  potential  to  significantly  reduce  cost  and  change  the  baseline  against  which  the 
cost/performance/requirements  trades  are  to  be  benchmarked.  The  description  of  CAIV 
within  this  broader  context  as  provided  in  the  Defense  Acquisition  Deskbook  is,  “CAIV  is 
a  strategy  that  entails  setting  aggressive,  yet  reahstic  cost  objectives  when  acquiring  de¬ 
fense  systems  and  managing  achievement  of  these  objectives.  Cost  objectives  must  bal¬ 
ance  mission  needs  with  projected  out-year  resources,  taking  into  account  existing  tech¬ 
nology,  maturation  of  new  technologies  and  anticipated  process  improvements  in  both 
DoD  and  industry.”  In  some  ways  CAIV  suffers  from  the  combinahon  of  too  many  ini- 
hatives  to  be  easily  explained.  Philosophically  CAIV  is  the  combination  of  all  the  best 
pracdces  affecting  cost. 
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PROGRAM 

PROGRAM 

DESCRIPTION 

PROGRAM 

STATUS 

EELV 

A  more  cost-effective  space 
launch  vehicle  for  medium  and 
heavy  lift  requirements 

Pre-Engineering  and  Manufacturing 
Development  (EMD)  phase,  start 
Dec.  1996 

AIM-9X 

Next  generation  Sidewinder  air- 
to-air  missile 

EMD  start  Jan.  1997 

TACMS- 

Upgrade  of  tactical  ground-to- 

Currently  in  Program  Definition 

BAT  P31 

ground  missile  -  new  seeker 

and  Risk  Reduction  (PDRR),  EMD 
start  in  1998 

MIDS 

Third  generation  secure,  jam- 
resistant,  conununication  system 
for  NATO  family 

EMD  contract  awarded  in  Mar. 

1994;  restructured  June  1994; 

CDR  in-process 

JASSM 

Long-range  air-to-surface  standoff 
missile 

Entering  2-year  competitive  PDRR 

CRUSADER 

155MM  self-propelled  Howitzer 
and  armored  re-supply  vehicle 

Completion  of  PDRR  in  FY  2000; 
single  contract  team 

JSF 

Advance  Strike  Fighter  Aircraft 

Pre-PDRR 

SBIRS 

Space-based  infrared  surveillance 
system  for  missile  defense 

Entered  EMD  for  GEO  in  FY  1996; 
PDRR  for  LEO  with  MS  II  in 

FY  1999 

Figure  14-1:  CAIV  Flagship  Programs 
(As  of  21  October  1996) 


14.2.1.2  Concepts.  The  implementation  of  CAIV  requires  new  thinking  about  program 
management.  If  cost  is  truly  to  be  the  key  driver  of  performance  and  schedule,  no  single 
cost-reduction  strategy  is  likely  to  be  sufficient.  All  cost-reduction  initiatives  must  be 
considered.  In  a  presentation  by  the  Institute  for  Defense  Analyses  at  the  Flagship  Work¬ 
shop  in  July  1996,  a  hierarchy  of  CAIV  cost  levers  was  proposed.  All  of  these  levers  are 
important  in  CAIV  implementation.  They  are  discussed  below  in  rough  order  of  poten¬ 
tial  benefit  for  most  programs: 

•  Cost/performance/requirements  trades.  This  is  the  essence  of  CAIV  and  will 
be  discussed  in  detail  in  following  sections. 

•  Acquisition  strategy.  Competition  is  the  greatest  lever  to  ensure  that  CATV 
objectives  are  met  that  the  government  has  in  the  early  stages  of  a  program. 
Because  of  this,  competition  should  be  maintained  as  long  as  economically 
practical. 

•  Concurrent  engineering/TPPD.  To  meet  an  aggressive  cost  target,  it  is  critical 
that  all  functional  planning  be  integrated  and  that  team  members  cooperate  to 
resolve  difficulties  early. 
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•  Contractor  enterprise  re-engineering.  The  lean  enterprise  philosophy  encour¬ 
ages  industry  to  concentrate  on  core  capabilities  and  to  develop  long-term  re¬ 
lationships  with  key  supphers  for  non-core  activities.  It  also  requires  that 
core  activities  be  conducted  with  maximum  efficiency. 

•  Commercial  specifications,  practices,  and  components.  Acquisition  reform 
has  enabled  use  of  commercial  specifications  and  practices  in  many  areas. 

The  use  of  commercial  components,  where  technically  feasible,  is  an  impor¬ 
tant  cost  reduction  tool  for  many  programs. 

DoD  is  striving  for  cost  savings  from  these  “cost  levers,”  which  will  enable  50  percent 
and  greater  reductions  in  cost  from  the  old  way  of  doing  business.  The  Joint  Direct  At¬ 
tack  Munition  (ID AM)  program  is  a  frequently  cited  example  of  a  program,  which  is 
achieving  this  magnitude  of  reduction  from  the  broad  impact  of  the  new  way  of  doing 
business. 

Figures  14-2  is  a  straight-forward  schematic  of  the  CAIV  process,  displaying  the  essen¬ 
tials  of  what  would  otherwise  call  for  a  complex  “wiring”  diagram  of  affordability  analy¬ 
sis,  cost  analysis  and  engineering,  and  cost  management. 


PARTICIPANTS  IN  THE  CAIV  PROCESS 
Environment  of  New  Process  and  Practices 


Concepts, 
Design,  and 
Cost  Data 


Requirements 


Figure  14-2;  Participants  in  the  CAIV  Process 
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14.2.2  Trade  Space 

The  preceding  has  consistently  addressed  the  tradeoff  process  as  cost/performance  and 
requirements  as  a  way  of  emphasizing  the  role  of  the  user  and  the  importance  of  the  tran¬ 
sition  from  the  requirements  process  to  contracting  for  system  performance  goals.  This 
emphasizes  the  different  nature  of  requirements  as  the  system  changes.  To  enhance  the 
effectiveness  of  CAIV,  programs  should  minimize  the  number  of  system  performance 
parameters  stated  in  the  Operational  Requirements  Document  (ORD)  at  Milestone  (MS) 

I.  This  allows  for  the  development  of  performance  objectives  that  are  achievable  and  af¬ 
fordable  based  on  actual  development  and  additional  analysis  during  PDRR.  If  the 
minimum  number  of  parameters  is  used  consistently  to  meet  the  users  real  needs,  greater 
leeway  will  be  provided  for  future  tradeoffs.  The  system  performance  parameters  called 
out  in  the  ORD  are  designated  key  performance  parameters  and  are  not  tradable  below  a 
threshold  value.  For  these  key  performance  parameters  the  trade  space  exists  between  the 
threshold  value  and  objective  value  with  both  values  stated  in  the  ORD  and  in  the  Acqui¬ 
sition  Program  Baseline  (APB).  These  values  are  refined  by  MS  II  and  become  part  of 
the  system  design  specification. 

For  technical  performance  parameters,  the  CAIV  threshold  and  objective  values  should 
be  the  same  as  those  in  the  APB.  For  CAIV  cost  threshold  and  objective  values,  potential 
problems  may  exist  because  they  are  equivalent  to  the  APB  values.  The  program  budget 
cannot  exceed  the  APB  cost  threshold  and  the  cost  threshold  is  specified  as  10  percent 
above  the  objective  value  [per  5000.2R,  part  3.2.1  and  3.2. 2.2].  This  may  provide  httle 
cost  room  to  solve  technical  performance  parameter  breaches. 

14.2.2.1  Performance.  To  some  extent  previous  attempts  at  cost/performance  trades 
have  been  the  victims  of  inflexible  requirements  from  the  user  or  over-specified  require¬ 
ments  by  the  acquirer.  Performance  goals  have  frequently  been  driven  by  available  tech¬ 
nology  because  the  contractor  and  Program  Management  Office  (PMO)  are  striving  for 
“the  last  ounce  of  performance.”  The  threshold  and  objective  values  for  key  performance 
parameters  should  be  developed  initially  as  the  user  translates  the  broadly  stated  mission 
need  from  the  mission  area  analysis  into  a  system  description  for  the  ORD.  An  analysis 
of  alternative  system  concepts  should  be  focused  on  determining  the  appropriate  technical 
performance  trades  prior  to  the  initial  ORD  and  APB  at  MS  I.  These  parameters  are 
stated  in  the  initial  ORD  and  APB  and  updated  at  each  milestone.  For  effective  con¬ 
tracting,  performance  must  be  stated  as  overall  system  performance  goals,  including  lo¬ 
gistics  performance  goals.  Performance  must  not  be  detail  specific,  quantified,  or  stated 
in  “how  to  do  it”  parameters.  In  all  cases,  the  user  and  acquirer  must  be  willing  to  accept 
lesser  performance  to  maintain  or  control  cost  within  the  trade  space.  Changing  the  cul¬ 
ture  regarding  lesser  but  acceptable  performance  is  critical  to  successful  implementation 
of  CAIV.  Thus,  the  user  must  be  an  integral  player  throughout  the  process  as  the  cost- 
performance/schedule/requirements  tradeoffs  are  made  in  each  phase  of  the  life  cycle. 

14.2.2.2  Early  Cost  Estimates.  Clearly  the  tradeoff  process  is  more  effective  if  it  can  be 
accomplished  earlier  in  the  design  process.  A  large  percentage  of  the  cost  is  determined 
by  a  small  percentage  of  the  design  decisions.  These  critical  cost-driving  design  deci- 
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sions  normally  occur  very  early  in  the  concept  selection  and  design  process.  Because  of 
this,  greater  success  is  expected  when  implementing  CAIV  for  programs  in  the  Concept 
Exploration  or  Program  Definition  and  Risk  Reduction  phases.  There  are  significant 
problems  estimating  production  and  Operating  and  Support  (O&S)  costs  this  early,  but 
these  estimates  can  be  updated  and  improved  over  the  life  cycle.  Improvement  of  these 
estimates  will  have  the  greatest  program  impact  if  competition  continues. 

14.2.3  Design-To-Cost 

How  is  CAIV  different  from  Design-to-Cost  (DTC)?  This  question  is  frequently  asked  in 
discussions  on  CAIV.  CAIV  embodies  more  than  the  tradeoff  process  that  is  DTC,  and 
there  are  key  conceptual  differences.  Under  CAIV  the  user  is  an  active  participant  in  the 
tradeoff  process  throughout  the  life  cycle.  This  was  not  the  case  with  DTC.  Another  key 
difference  is  a  more  flexible  requirement  based  on  threshold  mission  effectiveness.  Ear¬ 
lier  planning  in  the  life  cycle  with  an  iterative  refining  of  the  objectives  by  the  user  and 
acquirer  is  another  difference.  In  the  past  DTC  has  been  predominately  a  contractor’s 
process  executed  during  the  system  design.  In  simplest  terms,  consider  DTC  as  one  of  the 
tools  for  the  implementation  of  the  CAIV  concept. 

14.2.4  Process 

The  DoD  initiative  on  Integrated  Product  and  Process  Development  (IPPD)  and  Inte¬ 
grated  Product  Teams  (IPT)  is  central  to  the  implementation  of  CAIV.  This  initiative  is 
expected  to  be  implemented  within  both  the  contractor  and  government  organizations. 
Under  the  direction  of  the  government  Program  Manager  (PM),  a  CPIPT  will  establish 
the  program  cost  objectives  and  facilitate  the  cost-performance-requirements  tradeoff 
process.  From  the  outset,  this  team’s  membership  will  include  the  user;  contractor  repre¬ 
sentation  is  allowed  if  determined  to  be  appropriate  [see  5000.2R,  part  1,  section  1.6]. 
Other  members  will  vary  depending  on  the  phase  of  the  life  cycle,  but  membership  could 
include  the  Service  cost  center  and  the  OSD  Cost  Analysis  Improvement  Group  (CAIG) 
as  does  the  Joint  Air-To-Surface  Standoff  Missile  (JASSM)  program.  A  detailed  discus¬ 
sion  of  the  membership  and  roles  of  the  CPIPT  is  provided  in  the  “Life-Cycle  Cost- 
Performance  Concept  Paper.’’' 

The  CAIV  process  is  an  iterative  one  focused  around  the  PM  and  CPIPT.  The  PM  and 
CPIPT  work  with  the  overarching-IPT  representing  the  PEO,  Service  headquarters,  and 
OSD  to  determine  funding,  receive  programmatic  direction,  and  provide  program  status. 
The  PM  and  CPIPT  must  have  a  strong  working  relationship  with  the  user  community  in 
establishing  cost-effective  requirements  and  determining  priority.  The  PM  and  CPIPT 
have  a  number  of  supporting  acquisition  organizations  ranging  from  functional  support 
organizations  within  the  component  command  to  Service  cost  centers  providing  cost  es¬ 
timating  and  analysis.  Design  and  cost  analysis  by  the  contractors  provide  the  CPIPT 
with  the  information  necessary  to  analyze  cost/performance  tradeoffs.  This  circle  of  re¬ 
lationships  around  the  PM  and  CPIPT  enable  a  sequence  of  activities  necessary  to  ae- 
complish  CAIV.  These  activities  include  the  development  of  aggressive  and  affordable 


'  Attachment  to  Under  Secretary  of  Defense  memo  of  19  July  1995,  Subject:  Policy  on  Cost-Performance  Trade-Offs, 
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cost  goals,  implementation  of  incentives  to  encourage  the  accomplishment  of  these  goals, 
and  measurement  of  specific  CAIV  performance  through  tracking  of  metrics.  Metrics 
can  include  hfe-cycle  cost  components  such  as  Program  Acquisition  Unit  Cost  (PAUC), 
Average  Procurement  Unit  Cost  (APUC),  Average  Unit  Procurement  Cost  (AUPC),  and 
technical  metrics  such  as  Mean  Time  Between  Failures  and  Mean  Time  To  Repair. 

14.2.4.1  Setting  Aggressive  Cost  Targets.  Aggressive  cost  goals  are  developed  consid¬ 
ering  a  number  of  elements  including  available  resources,  costs  of  comparable  systems 
and  components,  mission  effectiveness  studies,  technology  based  trends,  and  the  use  of 
such  initiatives  as  lean  manufacturing  and  commercial  business  practices.  The  CPIPT 
must  use  these  elements  to  develop  initial  aggressive  cost  goals  while  balancing  issues 
within  the  following  framework: 

(1)  Using  affordability  as  the  key  criterion,  the  Service  headquarters  divides  a 
fixed  budget  among  competing  programs.  Here  the  cost  goals  are  used  in  devel¬ 
oping  a  budget  required  for  that  program,  which  is  compared  with  the  available 
dollars  in  the  POM  years  and  based  on  the  priority  level  estabhshed  by  the  Serv¬ 
ice,  JROC,  and  others.  This  fixed-budget,  which  is  based  on  the  priority  of  the 
program,  is  the  reality  of  what  is  available  for  structuring  the  program.  The  cur¬ 
rent  budget  may  be  less  constraining  in  the  out-years,  but  it  still  drives  the  pro¬ 
gram  acquisition  strategy. 

(2)  Using  mission  effectiveness  as  the  key  criteria,  the  user  and  Service  head¬ 
quarters  must  determine  “the  most  bang  for  the  buck”  of  the  proposed  system. 
Here  analytical  studies  begin  with  mission  area  analysis  and  analysis  of  alterna¬ 
tives,  and  they  result  in  a  set  of  requirements  in  a  Mission  Need  Statement  and 
Operational  Requirements  Document.  This  analysis  would  look  at  the  proposed 
program  in  terms  of  mission  effectiveness  versus  performance  requirements  and 
performance  requirements  versus  cost.  There  are  different  DoD  organizational 
elements  involved  in  this  analysis,  depending  on  the  Service:  Center  for  Naval 
Analyses  (Navy),  TRADOC  (Army),  Air  Combat  Command  (Air  Force),  and 
OSD  Program  Analysis  and  Evaluation  (PA&E).  These  studies  provide  the  nec¬ 
essary  tie  between  mission  requirements,  performance  parameters,  and  the  cost- 
effectiveness  required  of  the  system. 

(3)  The  PMO  would  normally  have  access  to  independent  research  and  contract 
studies  by  contractors  that  provide  concepts  and  cost  estimates  for  achieving  the 
required  system  performance  requirements.  These  concepts  and  associated  costs 
may  vary  widely  from  one  study  to  the  next,  but  they  provide  the  critical  contrac¬ 
tor  perspective  on  the  range  of  alternatives  and  also  provide  key  data  to  the  above- 
mentioned  analysis  of  alternatives  and  funding  exercises. 

Through  the  CPIPT,  the  PM  must  find  a  set  of  initial  cost  goals  that  provide  an  affordable 
budget  and  still  enable  the  system  to  meet  at  least  the  threshold  requirements  of  the  user. 
If  the  cost  goals  include  consideration  of  the  most  likely  cost  of  the  performance  and 
schedule  requirements,  a  legitimate  trade  space  for  cost/performance  tradeoffs  can  exist 
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and  the  cost  targets  can  have  the  necessary  reahsm  to  be  effective.  If  initial  realistic  cost 
goals  cannot  be  developed  through  this  trade  program  within  the  budget  affordabihty,  the 
program  is  not  viable.  The  initial  cost  goals  will  be  refined  at  each  stage  of  development 
to  ensure  a  balance  between  realistic  and  aggressive.  They  will  be  referred  to  as  cost 
goals  by  MS  I,  as  cost  targets  by  MS  II,  and  firm  cost  targets  by  MS  III. 

The  key  cost  targets  focus  on  unit  production  costs  and  operations  and  support  costs.  The 
AUPC  may  be  defined  in  several  ways.  Some  programs  such  as  JASSM  and  AIM-9X 
have  “bumper-to-bumper”  warranty  cost  (although  for  differing  periods)  included  in 
AUPC;  others  have  no  warranty  cost.  Further  complicating  this  definition  is  the  need  to 
specify  the  AUPC  of  the  total  planned  production  and  the  average  value  for  each  produc¬ 
tion  lot.  The  second  area  of  cost  focus  is  O&S  costs,  which  are  even  more  difficult  to 
predict.  Contractually,  operations  and  support  costs  may  best  be  handled,  as  several  of 
the  Flagship  Programs  have,  by  setting  aggressive  goals  for  key  performance  parameters 
that  drive  O&S  costs,  such  as  Mean  Time  Between  Failure  (MTBF)  and  Mean  Time  To 
Repair  (MTTR). 

14.2.4.2  Implementation  of  Incentives.  The  implementation  of  incentives  is  a  critical 
part  of  ensuring  the  necessary  changes.  These  incentives  can  be  either  positive,  for 
achieving  targets,  or  negative,  for  failure  to  meet  targets.  If  the  contractor  is  not  meeting 
the  program  cost  targets,  an  acquisition  strategy  could  be  structured  to  restart  competi¬ 
tion.  An  acquisition  to  provide  the  optimum  level  of  competition  by  phase  is  one  of  the 
most  effective  ways  to  ensure  cost  is  minimized.  Flagship  program  examples  are  the 
JASSM  and  EELV  Programs,  which  use  rolling  down-selects  with  the  final  development 
contract  competition.  These  example  programs  include  low-rate  initial  production  and  the 
incentive  of  continuation  in  a  sole  source  mode  as  long  as  the  final  cost  targets  structured 
during  the  final  competition  are  not  breached. 

In  many  programs  the  quantity  or  other  factors  prevent  the  ability  to  have  competition  in 
production.  In  these  situations,  the  use  of  award  or  incentive  profit  can  play  a  major  role. 
The  Crusader  Program  is  an  example  of  a  program  with  a  sole  source  contractor  in  devel¬ 
opment  through  procurement.  In  this  case,  the  award  fee  is  being  used  significantly  to 
motivate  contractor  performance.  This  is  in  an  environment  of  minimal  mil-specs,  mil- 
stds,  and  Contract  Data  Requirements  Lists  (CDRLs).  The  Space-Based  Infrared  Sys¬ 
tems  (SBIRS)  Program  uses  an  incentive  fee  to  share  the  cost  savings  between  govern¬ 
ment  and  contractor.  An  important  motivational  aspect  for  all  programs  is  the  shared  de¬ 
cision  role  through  participation  on  the  CPIPT. 

14.2.4.3  Earned  Value.  In  the  case  of  contracts  requiring  compliance  with  DoD 
Cost/Schedule  Control  Systems  Criteria  (C/SCSC)  or  Cost/Schedule  Status  Report 
(C/SSR)  requirements.  Program  Managers  and  their  IPTs  should  review  contractor 
planning  baselines  within  six  months  after  contract  award.  The  government’s  review 
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of  a  contractor’s  performance  measurement  baseline  is  known  as  an  Integrated  Base¬ 
line  Review  (IBR).  The  objectives  of  the  IBR  are  to: 

•  ensure  that  reliable  plans  and  performance  measurement  baselines  are  estab¬ 
lished,  which  (a)  capture  the  entire  technical  scope  of  work,  (b)  are  consistent 
with  contract  schedule  requirements,  and  (c)  have  adequate  resources  assigned 
to  complete  program  tasks; 

•  improve  the  use  of  costyperformance  data  by  government  and  contractor  pro¬ 
gram  managers  as  a  management  tool;  and 

•  reduce  the  number  of  C/SCSC  management  systems  reviews  based  on  insights 
developed  through  assessment  of  the  contractor’s  actual  implementation  of 
their  management  system  and  processes  on  the  instant  contract. 

14.2.5  Measuring  Performance  through  Tracking  of  Metrics 

There  is  a  necessity  for  validated  cost  models  to  track  life-cycle  cost  during  program  exe¬ 
cution.  The  govenunent  should  have  access  to  the  contractors'  models  and  methodology. 
This  does  not  mean  the  government  and  contractor  have  the  same  models,  but  they  work 
together  to  share  and  validate.  The  contractor’s  design-to-cost  system  must  provide  a 
flow-down  of  the  APUC  to  the  engineering  design  level,  with  status  reporting,  corrective 
actions,  and  trend  analysis.  The  reporting  process  must  be  made  a  part  of  the  contract 
statement  of  work.  The  Crusader  Program  found  that  the  models  used  for  trades  were  in¬ 
adequate  for  cost  tracking.  The  AIM-9X  Program  found  that  it  was  extremely  valuable  to 
establish  a  Govemment/Contractor  APUC  Working  Group  early.  Another  aspect  is 
maintaining  an  APUC  baseline  so  the  APUC  can  be  re-baselined  to  account  for  govern¬ 
ment-directed  design  changes,  quantity  changes,  and  economic  price  adjustments.  Any 
change  in  the  baseline  must  be  directly  traceable  so  that  the  cause  and  magnitude  are 
documented.  Please  note  the  prior  discussion  of  integrated  baseline  reviews  (14.2.4.3). 

With  regard  to  the  operations  and  support  costs  tracking  process,  it  has  been  handled  by 
the  Flagship  Programs  in  one  of  two  ways.  On  those  programs  where  the  contractor  has 
provided  a  warranty  as  part  of  the  APUC,  the  government  needs  to  be  concerned  only 
with  the  cost  models  at  the  time  of  warranty  negotiation.  Where  there  is  no  warranty,  the 
system  is  measured  through  test  and  analysis  of  the  technical  parameters  driving  O&S 
costs,  such  as  MTBF,  MTTR,  and  staffing  requirements.  Technical  performance  meas¬ 
urement  should  be  used  to  track  all  critical  performance  parameters  including  those  driv¬ 
ing  O&S  costs. 

14.2.6  Summary 

CAIV  is  the  key  strategy  in  the  management  of  all  system  acquisitions  in  the  Department 
of  Defense.  The  ability  of  the  CAIV  concept  to  achieve  significant  savings  will  be  dem¬ 
onstrated  in  the  Flagship  Programs.  However,  it  will  take  some  time  before  results  are 
available  (early  1997  and  beyond).  In  the  meantime,  all  major  defense  acquisition  programs 
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in  the  first  two  phases  of  the  life  cycle  were  charged  with  implementing  this  concept  and 
were  required  to  submit  a  paper  on  CAIV  implementation  by  July  1, 1996.  These  pro¬ 
grams  continue  to  annually  report  progress  on  this  concept  to  their  Milestone  Decision 
Authority.  This  chapter  is  largely  based  on  reference  (g)  below. 

14.2.7  Points  Of  Contact/References 

a.  OUSD(A&T),  Principal  Deputy  Director  Strategic  and  Tactical  Systems,  tele¬ 
phone  703-695-7417. 

b.  Defense  Systems  Management  College,  Faculty  Division,  telephone  703-805- 
3683. 

c.  Program  managers  referenced  in  Figure  14-1 . 

d.  Defense  Acquisition  Deskbook. 

e.  Kausal,  B.  A.,  “Controlling  Cost  -  A  Historical  Perspective,”  Program  Man¬ 
ager,  November-December  1996,  Defense  Systems  Management  College, 
Fort  Belvoir,  Virginia. 

f.  Land,  Gerry,  “Cost  As  an  Independent  Variable  (CAIV)  Philosophy,”  unpub¬ 
lished  e-Mail  text,  July  1996,  Defense  Systems  Management  College,  Fort 
Belvoir,  Virginia. 

g.  Rush,  Benjamin,  “Costs  as  an  Independent  Variable:  Concepts  and  Risks,” 
Acquisition  Review  Quarterly,  Spring  1997,  Defense  Systems  Management 
College,  Fort  Belvoir,  Virginia. 
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15 

LOGISTICS  PROGRAMMING  AND 

BUDGETING 


“General,  (Alain  C.  Enthoven  to  a  senior  USAF  officer  in  Germany),  I  don ’t 
think  you  understand.  I  didn  ’t  come  for  a  briefing.  I  came  to  tell  you  what 
we  have  decided.  ” 

Henry  L.  Treewhitt,  McNamara  (1971) 


15.1  OVERVIEW 

DoD  acquisition  programs  have  historically  operated  within  an  interlocking  set  of  three 
decision-making  systems: 

•  The  requirements  generation  system,  where  program  requirements  are  origi¬ 
nated,  validated,  and  assessed  for  Service  “jointures”  potential; 

•  The  acquisition  management  process,  where  programs  are  periodically  re¬ 
viewed  and  management  decisions  are  made  concerning  program  progress 
through  the  acquisition  phases;  and 

•  The  Planning,  Programming,  and  Budgeting  System  (PPBS),  where  program 
funding  is  managed. 

The  abihty  of  the  Program  Manager  (PM)  to  interface  effectively  with  these  three  sys¬ 
tems  is  essential  to  program  success. 

This  chapter  deals  with  one  subset  of  the  PPBS.  This  subset  involves  developing  the  ac¬ 
quisition  logistics  manager’s  input  to  the  program  office’s  portion  of  the  Service’s  Pro¬ 
gram  Objective  Memorandum  (POM);  and  the  acquisition  logistic  manager’s  input  to  the 
Service’s  Budget  Estimate  Submission  (BES)  as  part  of  the  biennial  budget  process. 

Many  logistics  managers  have  documented  logistics  support  planning,  and  many  others 
have  documented  contracting  documents  to  execute  the  plans.  However,  the  truly  suc¬ 
cessful  logistics  managers  have  effectively  documented  and  defended  the  logistics  por¬ 
tion  of  the  POM  and  budget.  These  are  the  people  who  have  the  resources  to  properly 
execute  the  plans. 
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15.2  PROGRAM  COST  CATEGORIES.  COST  OBJECTIVES.  AND  COST 
PERFORMANCE  TRADEOFFS 

Program  management  personnel  will  work  with  the  user  (see  DoDD  5000.1,  paragraph 
C.9)  to  identify  systems  performance  and  schedule  requirements,  perform  cost  related 
tradeoffs,  and  set  objectives  for  all  relevant  cost  categories.  Once  these  performance, 
schedule,  and  cost  objectives  have  been  set,  the  acquisition  process  will  make  cost  more 
of  a  constant  and  less  of  a  variable,  while  nonetheless  obtaining  the  needed  mihtary  ca¬ 
pability  of  the  system.  In  this  regard,  see  Chapter  14,  Cost  As  an  Independent  Variable 
(CAIV). 

Several  programs,  both  recently  and  in  the  past,  have  employed  CAIV  principals.  How¬ 
ever,  until  recently,  DoD’s  goal-setting  processes  have  been  largely  driven  by  an  unre¬ 
lenting  threat  (requirements  creep  to  match  a  changing  threat)  and  a  desire  to  capitalize 
on  technological  advances.  This  trend  toward  program  requirement  creep,  in  lieu  of  em¬ 
phasizing  cost/performance/schedule  tradeoffs  in  goal  setting  and  management,  has  con¬ 
tributed  to  a  historical  cost-growth  record  for  DoD  programs.  Research  has  shown  that 
virtually  all  700  acquisition  programs  have  experienced  cost  growth  over  the  past  25 
years.  The  objective  of  the  CAIV  initiative  is  to  ensure  that  constant  management  atten¬ 
tion  is  focused  on  controlling  costs  associated  with  both  new  and  fielded  DoD  systems. 

15.2.1  Cost  categories 

There  are  several  ways  costs  associated  with  a  program  must  be  defined  and  estimated, 
they  include  funding  appropriation,  work-breakdown  structure,  and  Life-Cycle  Cost 
(LCC)  categories.  These  are  defined  below: 

15.2.1.1  Breakdown  by  Funding  Appropriation.  These  include  Research,  Development, 
Test,  and  Evaluation  (RDT&E);  Procurement;  Operations  and  Maintenance  (O&M); 
Military  Construction;  and  Military  Personnel.  These  breakouts  are  necessary  to  develop 
internal  budgets  and  for  budget  requests  to  Congress. 

15.2.1.2  Breakdown  by  Work  Breakdown  Structure  (WBSL  The  WBS  is  a  tool  used  to 
specify  work  to  be  done  and  the  associated  costs  to  perform  the  work.  Military  Standard 
88 IB  provides  a  recommended  WBS  for  various  program  categories  including  aircraft, 
ships,  armored  vehicles,  etc.  It  accommodates  prime  mission  equipment,  systems  engi¬ 
neering,  program  management,  systems  test  and  evaluation,  training,  peculiar  support 
equipment,  data,  operational  site  activation,  initial  spares,  initial  repair  parts,  and  indus¬ 
trial  facilities.  Each  of  these  categories  is  further  broken  down  into  indentured  levels  of 
detail.  This  method  provides  an  organized,  structured  system  of  compartmentahzing 
work  and  its  associated  costs.  It  facilitates  detailed  visibility  into  those  parts  of  the  work 
that  are  expected  to  be  the  major  consumers  of  resources.  Further,  the  method  tracks  the 
contractors’  actual  work  performance  against  their  initial  cost  estimate  by  specific  task, 
i.e.,  work  packages.  The  progress  of  the  contractor’s  work  can  be  reported  within  the 
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WBS  structure.  The  historical  files  from  the  various  projects  and  programs  in  Service 
organizations  form  a  wealth  of  data  from  which  to  estimate  similar  future  projects. 

15.2. 1 .3  Breakdown  Bv  Tdfe-Cvcle  Cost  Categories.  The  breakdown  includes  Research 
and  Development  (R&D),  Procurement,  Operations  and  Support  (O&S),  and  disposal. 
Although  the  names  of  these  categories  are  similar  to  the  DoD  appropriations,  they  are 
not  the  same  and  have  different  meanings.  These  costs  are  addressed  in  Chapter  12,  Lo¬ 
gistics  Cost  Estimating,  paragraph  12.2.1.1. 

Note  that  LCC  includes  all  WBS  elements;  all  appropriations;  all  costs,  both  contract  and 
in-house,  for  aU  cost  categories. 

15.2.2  Cost  Estimating  Techniques 

This  topic  is  addressed  in  Chapter  12,  Logistics  Cost  Estimating,  paragraphs  12.4  and 
12.5. 

15.3  COST  DRIVERS 

Definitions  of  cost  estimating  terminology  would  not  be  complete  without  including  the 
frequently  used  term  “cost  driver.”  A  cost  driver  is  a  program,  system  characteristic,  or 
parameter  that  has  a  direct  or  indirect  effect  of  changing  cost.  A  cost  driver  may  even  be 
another  cost  element.  Examples  of  cost  drivers  include  numbers  of  systems,  numbers  of 
operating  sites,  numbers  of  systems  failures,  time  to  fix  broken  systems,  etc.  The  cost  of 
operations  and  support  is  driven  by  the  cost  of  individual  spare  parts  and  by  the  labor- 
hour  costs  of  operators  and  maintainers.  Thus,  costs  sometimes  drive  other  costs.  In 
some  instances  the  term  ‘*cost  drivers”  means  all  parameters  and  characteristics  that  drive 
costs;  but,  in  some  cases,  the  “cost  drivers”  is  intended  to  differentiate  the  parame- 
ters/character-istic  with  the  most  impact  on  costs.  Communication  and  documentation  on 
common  definitions  of  terms,  ground  rules,  and  assumptions  in  cost  estimating  is  an  ab¬ 
solute  necessity. 

15.4  PROGRAM  MANAGER'S  ROLE  IN  THE  PROGRAM  OBJECTIVE 
MEMORANDUM  (POMl  PROCESS 

Programming  and  budgeting  for  the  development,  production  and  logistics  support  for  a 
defense  system  must  be  accomphshed  within  the  framework  of  the  DoD  PPBS.  All  ac¬ 
quisition  programs  are  based  on  identified,  documented,  and  validated  mission  needs. 
Mission  needs  result  from  ongoing  assessments  of  current  and  projected  capability.  After 
the  Joint  Requirements  Oversight  Council  (JROC)  vahdates  the  mission  need  for  an  Ac¬ 
quisition  Category  (ACAT)  I  program,  the  Under  Secretary  of  Defense  (Acquisition  and 
Technology)  shall  convene  a  Milestone  0  DAB  to  review  the  Mission  Needs  Statement 
(MNS);  identify  possible  materiel  alternatives;  and  authorize  concept  studies,  if  they  are 
deemed  necessary.  For  ACAT  lA  programs,  the  JROC  or  the  cognizant  Office  of  the 
Secretary  of  Defense  Principal  Staff  Assistant  (OSD  PSA)  validates  the  mission  need  and 
process  integrity  in  compUance  with  DoDD  8000.15.  The  Assistant  Secretary  of  Defense 
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(Command,  Control,  Communication,  and  Intelligence)  convenes  a  Milestone  0  Major 
Automated  Information  System  Review  Council  (MAISRC).  Similar  parallel  actions 
apply  to  other  ACAT  levels.  A  favorable  Milestone  0  decision  moves  the  effort  into 
Phase  0,  Concept  Exploration;  but  it  does  not  yet  mean  that  a  new  acquisition  program 
has  been  initiated.  During  this  phase,  RDT&E  “study  money”  is  allocated  by  the  appli¬ 
cable  Service  or  the  Office  of  the  Secretary  of  Defense  (OSD)  for  development  of  the 
initial  analyses,  studies,  and  preparation  of  early  documentation  of  alternative  concepts. 
Also  during  Phase  0  activity,  the  initial  program  cost  estimate  is  prepared  and  submitted 
into  the  POM  process.  After  the  program  is  approved  at  Milestone  I,  the  sponsoring 
Service  assigns  a  Program  Element  (PE);  and,  from  that  time,  the  program’s  POM  fund¬ 
ing  levels  are  separately  tracked  by  that  PE  in  the  Service  and  OSD  databases.  The  pro¬ 
gram’s  BES  is  submitted  by  appropriation.  The  PM  has  primary  responsibihty  for  pre¬ 
paring  the  POM  input  and  BES  for  the  acquisition  logistics  requirements  identified  in  the 
logistics  planning  documentation.  The  process  of  submitting  the  BES  will  be  discussed 
in  paragraph  15.6. 

15.5  LOGISTICS  FUNDING  PROFILE 

The  information  needed  to  develop  the  logistics  support  portion  of  the  PM’s  budget 
comes  from  the  many  logistics  functional  elements.  Effective  logistics  budgeting  and 
funding  comes  from  the  acquisition  logistics  manager’s  understanding  of  the  information 
needed,  who  will  provide  it,  and  how  to  document  it  as  usable  input  to  the  PM’s  budget¬ 
ary  documentation.  Beginning  with  program  initiation,  the  acquisition  logistics  manager 
wiU  gather  and  document  costing  information  consistent  with  the  elements  as  spelled  out 
in  the  logistics  planning  documentation.  Logistics  support  cost  data  are  generally  dis¬ 
played  in  a  document  called  a  logistics  funding  profile.  This  profile  shows  the  budget 
requirements  stratified  in  the  logistics  areas  listed  below.  The  amount  of  detail  shown  in 
the  logistics  funding  profile  depends  on  the  level  of  management  attention  required  to 
keep  the  program  funding  risk  to  a  minimum.  Generally,  the  amount  of  detail  should 
match  the  level  of  detail  of  the  logistics  element  milestones  in  the  acquisition  logistics 
planning  documentation.  For  each  activity  shown  in  the  logistics  milestone  charts  there 
should  be  a  corresponding  cost  entry  in  the  funding  profile. 

The  logistics  funding  profile  should  have  a  section  for  each  element  of  logistics  as  they 
are  discussed  in  the  logistics  management  plan.  Additionally,  the  logistics  funding  pro¬ 
file  should  provide  a  summary  by  funding  appropriation,  a  summary  of  program  descrip¬ 
tion,  and  the  assumptions  upon  which  the  budget  is  based.  Costs  in  each  of  the  elements 
described  below  will  be  based  on  an  appropriate  method  of  cost  estimating  linked  to  Ac¬ 
quisition  Reform  initiatives  including  analysis  by  the  program  office. 

15.5.1  Maintenance 

This  element  is  for  actual  repair-type  maintenance  as  established  by  the  system’s  mainte¬ 
nance  plan.  The  various  subelements  of  maintenance  include  requirements  for  depot  and 
intermediate  investment  costs,  test-bed  facilities  investment,  repair  costs  including  depot 
and  intermediate  repair,  and  support/training-related  repair.  Particular  emphasis  is  now 
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required  in  the  area  of  contractor  maintenance  services.  Some  special  analysis  studies 
and  plans  may  sometimes  be  included.  Investment  costs  for  maintenance  should  not  du¬ 
plicate  requirements  identified  in  other  areas,  such  as  support  equipment  and  computer 
resources  support.  Primary  plant  equipment  that  is  unique  to  depot  or  intermediate  repair 
facihties  should  be  included  as  investment  costs.  Past  experience  from  contracting  for 
maintenance  and  from  the  Visibility  and  Management  of  Operations  and  Support  Cost 
(VAMOSC)  database  may  be  apphcable  as  source  information  on  maintenance. 

15.5.2  Technical  Data 

This  element  normally  refers  to  costs  associated  with  purchasing  operator  and  maintainer 
technical  manuals  and  depot  repair  standards.  Additionally,  this  element  includes  re¬ 
quirements  for  the  development,  in-process  review,  production,  vahdation,  verification, 
distribution,  and  updating  of  technical  data  and  the  associated  data  records.  It  also  in¬ 
cludes  management,  review,  and  source  data.  Specific  subelements  to  be  considered  are 
technical  orders/manuals  and  associated  changes,  technical  orders/manuals  management, 
drawings/reprocurement  data,  planned  maintenance  system  requirements,  analysis,  stud¬ 
ies,  plans,  and  other.  Sources  of  information  upon  which  to  base  the  estimate  are  analy¬ 
sis,  past  contract,  and  field  activity  tasking  orders.  It  is  not  unusual  to  see  back-up  data, 
which  differentiates  between  the  cost  of  technical  data  pages  in  categories  such  as  pure 
text,  text  and  graphics,  hsts  of  information  such  as  parts  Usts,  and  paper  copy  as  com¬ 
pared  to  electronic  methods.  Further  breakout  details  are  also  common,  including  opera¬ 
tion  manuals  versus  maintenance  manuals;  manuals  for  organizational,  intermediate,  and 
depot;  and/or  breakouts  for  structural,  electronics,  and  propulsion. 

15.5.3  Supply  Support 

This  element  summarizes  funding  requirements  for  spares  and  repair  parts.  Require¬ 
ments  for  spares  for  training  hardware  and  pecuhar  support  equipment  and  outfitting 
buy-outs  for  aviation  programs  should  also  be  considered.  Specific  subelements  to  be 
considered  are  development/test  spares  and  repair  parts;  interim/initial  spares  and  repair 
parts,  including  depot  and  intermediate  maintenance  support  stocks;  on-board  repair 
parts;  contractor  support  spares  and  repair  parts;  site  outfitting,  replenishment  spares  and 
repair  parts;  supply  plans  and  analysis;  and  other.  These  cost  requirements  should  be 
consistent  with  supply  support  planning  data  and  provisioning  requirements.  Sources  of 
this  information  include  both  the  program  office  analysis  in  view  of  Acquisition  Reform 
initiatives,  past  contracts,  and  the  many  contracts  awarded  and  managed  at  the  supply 
centers. 

15.5.4  Support  Equipment 

Support  equipment  (SE)  cost  requirements  should  be  projected  for  cdl  planned  levels  of 
maintenance,  test  sites,  training  sites,  etc.  Specific  subelements  to  be  considered  are 
common  support  equipment;  automated  test  equipment,  including  test  program  sets, 
tools,  jigs  and  fixtures;  cahbration  standards;  support  equipment  support  acquisition; 
analysis,  plans;  data;  etc.  The  primary  source  of  data  is  past  program  contracts.  But  SE  is 


15-5 


provisioned  in  the  supply  system,  and  inventory  control  point  contracts  are  also  regularly 
used  sources. 

15.5.5  Computer  Support  Resources 

This  element  summarizes  the  requirements  for  computer  resources  for  the  post-production 
software  support  of  materiel  systems.  Data,  compilers,  hardware,  and  sometimes  unique 
training  required  to  set  up  the  Software  Support  Activity  (SSA)  are  covered  here.  Other 
specific  subelements  are  software  support,  software  support-associated  hardware,  com¬ 
puter  development,  software  documentation,  independent  testing,  support  software,  and 
simulation  support.  These  should  coincide  with  the  computer  resources  planning  docu¬ 
mentation.  Sources  for  this  estimating  data  are  past  contracts  for  software  support,  which 
may  include  both  prime  contractors  and  other  related  contracts  and  field  activity  tasking 
orders. 

15.5.6  Facilities 

This  element  includes  miUtary  construction,  operations  and  maintenance  minor  construc¬ 
tion  appropriation  costs,  public  works/facihties  engineers,  and  utility  requirements.  Spe¬ 
cific  subelements  include  mihtary  construction  planning  and  design,  miUtary  construc¬ 
tion,  operation  and  maintenance  minor  construetion,  unspecified  minor  construction,  fa- 
cihties  engineering/public  works  support,  utihties,  facihties  analysis  and  plans,  and  other. 
Past  contracts  with  weapons  systems  original  equipment  manufacturers  rarely  include 
Unes  for  mihtary  construction.  Contract  information  from  separate  agencies,  such  as  the 
claimant  civil  engineering  departments  or,  in  the  case  of  the  Navy,  the  Naval  Facihties 
Command,  will  be  the  sources  of  planning  and  cost-estimating  data. 

15.5.7  Training  and  Training  Support 

All  training  course  requirements  from  development  to  instructor  services  are  part  of  this 
element,  including  training  equipment,  aids,  and  training  simulators.  Specific  subele¬ 
ments  are  training  courses  which  include  development,  initial  and/or  contractor  training 
services,  technical  training  equipment,  training  devices/aids,  analysis  and  studies,  train¬ 
ing  equipment  installation,  engineering  technical  services,  etc.  These  requirements  must 
coincide  with  the  appheable  tasking  in  the  training  master  plan.  Past  contracts  often  in¬ 
clude  hsts  of  individual  training  devices  and  their  costs. 

15.5.8  Acquisition  Logistics  Management 

This  element  covers  all  management  activities  for  the  entire  logistics  program,  which  in¬ 
cludes  supportabihty  analyses  costs  not  covered  under  dehverables  for  other  elements 
shown  above.  Subelements  could  include  management.  Level  of  Repair  Analysis 
(LORA),  Rehabihty  Centered  Maintenance  (RCM),  studies  and  plans,  etc.  Thus,  all  of 
the  logistics  performance  needs  generally  defined  as  maintenance  planning  or  acquisition 
logistics  management  could  be  addressed  in  this  section. 
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15.5.9  Related  Programs 

Related  programs  include  requirements  for  all  other  support  estimates  under  the  PM’s 
purview.  Specific  subelements  include  configuration  management,  installation,  handling 
equipment,  containers,  packaging,  handling,  storage,  transportation,  and  hazardous  mate¬ 
riel  control  and  management.  Identification  should  be  made  of  any  other  support-related 
activities,  such  as  contractor  or  government  laboratories  and  field  activities  that  require 
DoD  resources  in  any  acquisition  phase.  Additionally,  events  such  as  special  maintain- 
abihty  demonstrations,  logistics  demonstrations,  maintenance  engineering  conferences, 
etc.  that  the  acquisition  logistician  is  specifically  sponsoring  (or  otherwise  wants  budget 
visibility  for),  should  be  included  in  this  portion  of  the  funding  profile.  Sources  of  esti¬ 
mating  data  are  generally  historical  contracts  and  program  office  analyses  in  view  of  Ac¬ 
quisition  Reform  initiatives. 

15.6  THE  BUDGET  FORMULATION  PROCESS 

In  ideal  situations  the  full  membership  of  the  acquisition  logistics  team  will  be  involved 
in  the  budget  development  process.  At  times  it  may  be  necessary  for  the  acquisition  lo¬ 
gistics-integrating  individual  or  lead  logistician  to  create  the  initial  draft  of  the  logistics 
funding  profile  and  to  circulate  it  for  coordination  and  correction  among  his  team.  The 
process  starts  with  a  call  for  the  budget  input  from  the  program  office  financial  manager. 
However,  the  budget  call  starts  earlier  from  higher  authority;  and  the  calendar  of  budget 
events  can  be  determined  in  advance.  Typically,  the  budget  call  will  forward  program- 
level  budget  planning  information.  The  planning  information  includes  the  program  de¬ 
scription,  continuing  development  activities,  numbers  or  schedules  for  systems  procure¬ 
ments,  delivery  sites,  user  site  stand-ups,  planned  operational  tempos  (repair  items  and 
manpower  numbers  and  costs),  and  similar  information.  The  logistics  cost  estimator 
must  add  three  other  items  of  planning  information.  These  items  are  program  office 
planning  information  (para  15.4),  logistics  element  planning  information  (para  15.5),  and 
user  scenario-related  information. 

Each  logistics  element  cost  is  estimated  for  each  of  the  years  covered  in  the  budget  caU. 
The  cost-estimating  “back-up”  is  documented.  The  back-up  is  the  methodology,  data 
sources,  ground-rules,  assumptions,  calculation  methods  (model  or  formulas),  etc.,  used 
in  calculating  the  budget.  The  budget  profile,  or  spreadsheet,  is  documented  showing 
appropriation  summaries;  and  the  budget  back-up  books/files  are  created.  The  budget  is 
coordinated  with  the  logistics  element  members  of  the  IPT,  and  the  approved  logistics 
budget  is  submitted  to  the  program  financial  manager.  It  should  be  noted  that  documen¬ 
tation  of  budget  back-up  is  an  essential  step  in  the  process.  Parts  of  this  information  may 
or  may  not  be  forwarded  with  the  budget  inputs  to  the  program  financial  manager.  This 
documentation  is  especially  critical  in  view  of  the  likelihood  of  personnel  turnover  dur¬ 
ing  the  life  cycle  of  a  weapons  system  acquisition.  The  back-up  information  makes  fu¬ 
ture  adjustments  to  the  budget,  in  response  to  budget  drills,  a  matter  of  recalculation 
rather  than  starting  from  a  clean  slate. 


15-7 


The  inputs  from  all  of  the  program  functional  elements,  such  as  the  systems  engineers, 
production  managers,  testers,  logisticians,  etc.,  are  consohdated  by  appropriation  sum¬ 
mary.  The  program  budget  submission  is  then  ready  for  submission  through  the  levels  of 
the  Components’  comptrollers;  OSD-sponsoring  offices  and  comptrollers;  and,  finally,  to 
the  President’s  budget.  At  the  program  level  there  are  generally  four  appropriations  “one 
liners;”  they  are  total  program  funding  for  RDT&E,  Procurement/Production,  O&M,  and 
Mihtary  Construction  (MILCON).  Even  though  most  of  the  O&M  and  all  of  the 
MELCON  are  user  or  claimency  inputs  to  the  budget,  they  are  shown  on  the  program 
budget  for  continuity.  The  program  manager  needs  this  total  program  cost  visibihty  to 
properly  advocate  the  interrelated  requirements. 

The  budget  inputs  are  updated  nearly  continuously  because  of  the  biennial  budget  proc¬ 
ess,  budget  cuts,  and  program  changes  in  schedule  from  many  sources.  The  program  fi¬ 
nancial  manager  regularly  requires  very  quick  turnaround  to  budget  drills.  The  experi¬ 
enced  acquisition  logistics  manager  anticipates  this  requirement  and  has  sufficient  budget 
back-up  information  ready  to  make  adjustments,  prepare  impact  statements  for  the 
changes,  and  forward  the  re-submittal. 

15.7  DOCUMENTING  THE  LOGISTICS  FUNDING  PROFIT  S 

Individual  DoD  organizations  may  impose  locally  standardized  budget  documentation 
formats.  The  Army  has  required  submittal  of  budget  information  in  a  spreadsheet  format 
called  the  ACET  model.  The  model  is  more  of  a  spreadsheet-reporting  format  than  it  is  a 
model  since  each  organization  develops  and  programs  algorithms  into  the  spreadsheet. 
The  Navy  has  used  the  Logistics  Requirements  and  Funding  Plan  (LRFP)  and  its  varia¬ 
tions  for  over  ten  years. 

The  most  useful  logistics  funding  profiles  are  those  that  the  individual  integrating  logisti¬ 
cian  has  developed  to  satisfy  requirements  for  managing  the  acquisition  logistics  pro¬ 
gram.  There  is  usually  a  very  close  match  between  the  level  of  detail  in  the  logistics 
planning  document  and  its  companion  document — the  logistics  funding  profile.  Com¬ 
plex  programs  will  frequently  require  logistics  element  plans  containing  milestone  detail 
to  the  fifth  or  sixth  level  of  indenture.  This  reflects  the  level  of  management  attention 
intended  by  the  lead  logistician.  Every  milestone  and  activity  described  in  the  logistics 
plan  will  require  funding  resources  for  execution  of  the  plan. 

For  example,  under  the  faciUties  element,  there  may  be  a  milestone  for  a  site  survey  at 
the  training  location  in  a  given  month  during  the  EMD  phase  and  another  milestone  for  a 
site  survey  for  each  of  the  gaining  organizations  during  succeeding  quarters  of  that  phase. 
One  would  expect  that  each  of  the  activities  would  be  described  in  the  logistics  plan  and 
that  the  funding  requirements  for  each  of  the  site  visits  would  be  evident  in  the  logistics 
funding  profile.  The  logistics  funding  profile  is  provided  to  the  program  budget/financial 
manager  for  consohdation  into  the  overall  program  budget  submission. 

Logistics  budget  back-up  documentation  is  of  utmost  importance.  This  back-up  docu¬ 
ments  the  justification,  rational,  estimation  methodology,  ground  rules  and  assumptions. 
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formulas,  cost  estimating  relationships  (CERs),  etc.,  used  to  eome  up  with  the  dollar  val¬ 
ues  for  eaeh  logistics  cost  element.  Because  there  are  numerous  people  who  participate 
in  the  budget  formulation  exercise  and  frequent  and  regular  turnovers  of  the  budget  for¬ 
mulation  team  members,  the  back-up  is  an  absolute  necessity.  The  almost  constant  drills 
associated  with  defending,  adjusting,  and  resubmitting  the  budget  and  the  ease  with 
which  this  is  accomplished  will  be  directly  proportional  to  the  completeness  of  the 
budget  back-up  documentation. 
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16 

COST  ANALYSIS  STRATEGY 
ASSESSMENT  MODEL  (CASA) 


16.1  OVERVIEW 


Logistics  We  Holler 
Costs  Many  a  Dollar. 

So  Leave  It  to  Last 
‘Cause  We're  so  Short  of  Cash. 

Anon. 


The  Cost  Analysis  Strategy  Assessment  Model  (CASA)  was  developed  by  the  Defense 
Systems  Management  College  (DSMC)  in  response  to  a  broad  range  of  requirements 
gathered  from  many  of  the  Services’  acquisition  program  offices.  Over  the  past  several 
years  the  model  has  been  validated  and  used  successfully  by  all  of  the  DoD  Services,  in¬ 
dustry  contractors,  and  other  government  agencies  such  as  the  Federal  Aviation  Admini¬ 
stration  (FAA)  and  the  National  Oceanic  and  Atmospheric  Administration  (NOAA).  The 
model  has  evolved  to  the  current  3.01  version  and  more  enhancements  are  planned  as 
user  requirements  evolve. 

This  article  is  designed  to  acquaint  the  reader  with  a  useful,  general  purpose  Life  Cycle 
Cost  (LCC)  model,  to  announce  that  the  model  continues  to  be  available,  and  that  model 
upgrades  are  planned.  The  article  summarizes  the  PM’s  need  for  a  LCC  model,  discusses 
what  constitutes  a  useful  model,  and  specifically  describes  the  CASA  model. 

16.2  THE  REQUIREMENT  FOR  AN  LCC  MODEL 

The  PMs  need  a  tool  that  will  focus  the  efforts  of  the  Integrated  Product  Team  (IPT). 
They  need  a  concise  method  of  assuring  themselves,  program  management,  and  decision¬ 
makers  at  aU  levels  that  reasonable  decisions  are  being  made.  A  review  of  the  policies, 
definitions,  and  objectives  of  Systems  Engineering  (SE)  and  Acquisition  Logistics  in 
DoD  5000.2-R  will  lead  to  the  conclusion  that  an  effective  system  support  program  is 
one  that  provides  support  and  achieves  the  user’s  readiness  requirement(s)  using  the  most 
life-cycle  cost-effective  approach.  The  bottom  hne  of  the  PM’s  efforts  must  focus  on 
these  two  key  quantifiable  requirements;  maximized  mission  readiness  and  minimized 
total  cost 


The  PM  must  ensure  that  the  LCC  factors  are  developed  in  a  timely  manner  and  that  they 
influence  system  design  and  systems  engineering  processes  during  all  acquisition  phases. 
In  accomplishing  this  goal,  the  PM  needs  a  comprehensive,  accurate,  and  current  LCC 
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estimate  to  support  each  management  decision  where  cost  is  significant.  There  are  few 
decisions  made  during  a  program’s  life  cycle  that  do  not  affect  LCC.  An  LCC  estimate 
should  have  sufficient  accuracy  to  permit  comparison  of  relative  costs  of  design  and  ac¬ 
quisition  alternatives  under  consideration  by  management.  In  other  words,  LCC  is  a  de¬ 
cision  aid;  and  the  LCC  estimate  should  capture  enough  of  the  total  ownership  costs  to 
facilitate  well-informed  decisions.  The  two  main  goals  of  LCC  analysis  are  to:  (1)  iden¬ 
tify  the  total  cost  of  alternative  means  of  countering  a  threat,  achieving  production 
schedules,  and  attaining  system  performance  and  readiness  objectives  and  (2)  estimate 
the  overall  cost  impact  of  the  various  design  and  support  options. 


The  decisions  with  the  greatest  chance  of  affecting  LCC  and  identifying  savings  are 
clearly  those  impacting  acquisition  and  Operating  and  Support  (O&S)  costs  that  are  un¬ 
dertaken  in  the  early  stages  of  system  development  (concept  exploration,  program  defi¬ 
nition,  and  risk  reduction  phases).  But,  this  does  not  imply  that  LCC  tradeoff  analyses  are 
not  useful  during  later  program  phases.  During  the  production,  deployment/fielding,  and 
operational  support  phase,  the  evaluation  of  actual  readiness  data  and  resource  consump¬ 
tion  information,  which  are  taken  from  maintenance  data  collection  systems,  regularly 
lead  to  identification  of  “bad  actors”  in  need  of  corrective  actions,  such  as  improved  reli¬ 
ability  through  an  Engineering  Change  Proposal  (ECP). 

16.3  CHARACTERISTICS  OF  A  USEFUL  LCC  MODET. 


Rodney  Stewart  describes  the  most  valuable  automated  cost-estimating  tools  as  “the  ge¬ 
neric  computer  tools  that  can  be  used  for  any  application  . . .”  Blanchard  and  Fabrycky 
say  the  model  should  be: 

•  comprehensive,  include  all  relevant  factors,  and  be  reliable  in  terms  of  repeat¬ 
ing  results; 

•  representative  of  the  “dynamics”  of  the  system  or  product  being  evaluated  and 
be  sensitive  to  the  relationships  of  key  input  parameters; 

•  flexible  to  the  extent  that  the  analyst  can  evaluate  overall  system  requirements 
as  weU  as  the  individual  relationships  of  various  system  components.  In  the 
analysis  process,  one  may  wish  to  view  the  system  as  a  whole,  identify  high- 
cost  contributors,  evaluate  one  or  more  specific  components  of  the  system  in¬ 
dependent  of  other  elements,  initiate  changes  at  the  component  level,  and  pres¬ 
ent  the  results  in  the  context  of  the  overall  system; 

•  designed  to  simplify  timely  implementation  because,  unless  the  analyst  can  use 
the  model  in  a  timely  and  efficient  manner,  it  is  of  httle  value;  and 
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•  designed  so  it  can  be  modified  to  incorporate  additional  capabilities.  For  exam¬ 
ple,  it  may  be  necessary  to  expand  (or  tailor)  certain  facets  of  the  cost  break¬ 
down  structure  to  gain  additional  visibility. 

An  LCC  estimate  should  have  sufficient  accuracy  to  permit  comparison  of  relative  costs  of 
design  and  acquisition  alternatives  under  consideration  by  management.  This  statement 
means  that  an  LCC  model  serves  as  a  decision  aid,  and  the  model  needs  to  capture  enough 
(not  necessarily  all)  of  cost  of  ownership  to  facilitate  well-informed  decisions.  The  model 
developer  identifies  the  main  cost  drivers  of  LCC  and  creates  model  algorithms  to  capture 
these  costs. 

A  general-purpose  model,  which  captures  the  costs  of  a  systems  major  end  item  in  terms 
of  production,  initial  support  items,  operational  use,  and  also  the  recurring  costs  on  all  of 
the  ten  support  elements,  can  be  expected  to  produce  a  good  LCC  estimate. 

The  cost  analysis  process  includes  the  use  of  a  detailed  life-cycle  cost  model  and  aspects 
of  risk,  sensitivity,  and  data  comparison  analyses.  Also,  Research,  Development,  Test, 
and  Evaluation  (RDT&E)  cost  concerns  as  well  as  acquisition,  operation,  and  support 
costs  over  the  effective  life  of  the  system  are  included.  Thus,  a  good  life-cycle  model  cov¬ 
ers  the  entire  life  of  a  system,  from  its  initial  research  cost  to  those  costs  associated  with 
yearly  maintenance.  Also,  a  good  life  cycle  model  covers  spares,  training  costs,  and  other 
expenses  that  are  incurred  once  the  system  is  delivered. 

The  analyst  formulates  the  problem  statement  to  be  analyzed,  selects  the  appropriate 
model,  and  collects  the  appropriate  amount  of  model  input  data.  (Some  model  data  may 
be  left  blank  if  it  is  not  relevant  to  the  problem  statement.)  The  analyst  also  runs  the 
model  (including  selected  sensitivities)  and  draws  certain  conclusions  fi*om  the  model  out¬ 
puts.  Later  discussion  will  show  that  the  CASA  model  fits  all  of  these  requirements. 
Professor  Blanchard  recently  stated  that  the  CASA  model  is  the  best  LCC  model  available 
today. 

16.4  DISCUSSION  OF  AVAILABLE  COST  MODELS 

Research  shows  that  a  wide  variety  of  LCC  models  have  been  developed.  Some  of  these 
models  are  special  purpose  and  others  are  general  purpose.  The  government  has  regularly 
required  that  proposing  contractors  use  the  “government  approved”  models  in  estimating 
the  cost  of  ownership  of  the  proposed  solution.  This  requirement  ensures  that  all  of  the 
contractors  and  government  LCC  estimates  are  comparable,  repeatable,  and  understand¬ 
able.  Many  of  these  models  are  cataloged  in  the  DoD  Acquisition  Logistics  Guide  distrib¬ 
uted  by  the  Logistics  Support  Activity  (LOGSA),  an  agency  of  the  Army  Material  Com¬ 
mand  that  serves  all  of  DoD  in  the  area  of  logistics  supportability  assessment  and  related 
tools. 

Interviews  and  surveys  of  many  industry  representatives  have  resulted  in  a  finding  that 
many  government  models  were  considered  unnecessarily  complex  and  “input  data 
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hungry.”  Both  industry  and  government  program  managers  need  a  flexible  model  that  can 
operate  effectively  with  tailored  levels  of  input  detail,  from  simple  to  complex,  depending 
on  the  decision  being  considered. 

16.5  THE  CASA  MODET. 

The  CASA  model  is  basically  a  management  decision-aid  tool  based  on  LCC.  CASA  is  a 
set  of  analysis  tools  formulated  into  one  functioning  unit.  It  collects,  manipulates,  and 
presents  as  much  of  the  total  cost  of  ownership  as  the  user  desires.  It  contains  a  number 
of  programs  and  submodels  that,  along  with  LCC  comparisons  and  summations,  allow  the 
user  to  generate  program  data  files,  perform  life-cycle  costing,  perform  sensitivity  analysis, 
and  perform  LCC  risk  analysis.  CASA  offers  a  wide  variety  of  preprogrammed  output 
report  formats  designed  to  support  the  analysis  process. 

CASA  covers  the  entire  life  of  the  system,  from  its  initial  research  costs  to  those  associ¬ 
ated  with  yearly  maintenance.  It  also  covers  spares,  training  costs,  and  other  expenses 
once  the  system  is  delivered.  Currently,  RDT&E  and  production  costs  are  “throughput” 
costs,  i.e.,  they  are  not  derived  by  the  model;  they  are  input  and  reported  in  some  report 
outputs  depending  on  their  relevance  to  the  analysis.  The  model  calculates  and  projects 
the  O&S  costs  over  the  20  to  30  years  of  system  operation.  RDT&E  and  production  cost- 
estimating  modules  are  being  considered  in  response  to  numerous  user  requests. 

The  CASA  model  employs  some  82  algorithms  with  190  variables.  Only  a  small  number 
of  the  inputs  are  mandatory.  Most  of  the  inputs  are  optional  and  are  subject  to  tailoring  to 
the  needs  of  the  analysis.  CASA,  therefore,  is  a  relatively  “contact”  model  designed  to  facili¬ 
tate  well-informed  decisions  while  holding  model  input  data  gathering  to  a  moderate  level. 

CASA  works  by  taking  the  data  entered,  calculating  the  projected  costs,  and  determining 
the  probabilities  of  meeting,  exceeding,  or  falling  short  of  any  LCC  target  value.  CASA 
offers  a  variety  of  strategy  options  and  allows  for  alteration  of  original  parameters  to  ob¬ 
serve  the  effects  of  such  changes  on  strategy  options. 

At  any  number  of  program  junctions,  inputs  may  be  saved  and  calculations  may  be  made  to 
that  point  for  later  evaluation.  Eurthermore,  CASA  will  accept  only  correct  input.  The  CASA 
checks  all  data  as  it  is  entered;  incorrect  data  will  cause  the  cursor  to  stop  and/or  alert  the  user. 

CASA  can  be  used  for  a  wide  range  of  analysis  tasks,  such  as: 

•  LCC  estimates, 

•  tradeoff  analyses, 

•  repair-level  analyses, 

•  production-rate  and  quantity  analyses. 
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•  warranty  analyses, 

•  spares  provisioning, 

•  resource  projections  (e.g.  manpower  and  support  equipment), 

•  risk  and  uncertainty  analyses. 

•  cost-driver  sensitivity  analyses, 

•  reliability  growth  analyses, 

•  operational  availability  analyses  with  automated  sensitivity  analysis, 

•  spares  optimization  to  achieve  readiness  requirements,  and 

•  operation  and  support  cost  contribution  by  individual  line  Replaceable  Units  (LRUs). 

16.5.1  CASA  Model  Version  3.01 

CASA  version  3.01  has  been  distributed  since  1995.  This  version  expands  the  number  of 
hardware  items  (repairable  candidates)  from  145  to  2,000.  This  feature,  along  with  the  LCC 
summation  feature,  virtually  eliminates  any  limitation  on  the  “size”  of  a  system  that  can  be  ana¬ 
lyzed.  The  model  runs  well  on  386, 486,  and  Pentium  PCs.  It  requires  four  to  five  megabytes 
of  hard  drive  space,  depending  on  the  size  of  hardware  data  files.  The  program  currently  runs 
best  in  a  DOS  environment  since  it  requires  580K  of  RAM  to  operate  properly. 

16.5.2  CASA  Model  Version  4.0 

The  newest  version  of  CASA  is  in  a  Windows  95/NT  format.  This  version  includes  many 
new  features,  including  an  embedded  hypertext,  paperless  technical  manual,  and  embedded 
computer-based  training  (CBT).  The  new  model  will  retain  aU  of  the  functionality  of  the 
previous  versions,  plus  add  the  following  features; 

•  ability  to  assign  an  operational  availability  target  to  be  used  in  sparing  to  avail¬ 
ability  calculations; 

•  more  flexibility  in  describing  maintenance  levels,  i.e.,  regional  maintenance; 

•  ad  hoc  rather  than  canned  output  reports  and  graphical  output  formats; 

•  digital  technical  manual  imbedded  into  hyperlinked  help  files;  and 

•  CBT  and  “wizard”-type  examples. 
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Version  4.0  for  Windows,  like  version  3.01  for  DOS,  expanded  the  number  of  hardware 
items  (repairable  candidates)  from  145  to  2,000.  This  feature,  along  with  the  LCC  sum¬ 
mation  feature,  virtually  eliminated  any  limitation  on  the  “size”  of  a  system  that  can  be 
analyzed.  Other  new  features  are  being  considered  in  response  to  user  requirements. 

16.6  SOURCES  OF  THE  CASA  MODET. 

The  CASA  model  comes  compressed  on  two  program  file  disks;  one  disk  contains  the 
user’s  manual.  There  are  a  variety  of  sources  of  the  model.  Some  sources  distribute  the 
model  essentially  free,  but  they  offer  limited  user  support.  Other  sources  distribute  the 
model  for  a  modest  fee  to  recover  distribution  and  technical  support  costs.  LOGSA  is 
preparing  to  begin  the  distribution  of  CASA  as  a  module  of  the  logistics  manager’s  tool 
set  called  Logistics  Planning  and  Requirements  Simplification  (LOGPARS).  Three  points 
of  contact  for  internal  U.S.  distribution  of  the  model  are: 

•  Defense  Systems  Management  College,  Logistics  Management  Department, 

(703)  805-2497 

•  US  Army  Materiel  Command,  Logistics  Support  Activity  (LOGSA), 

(205)  955-988 

•  MAR-YAN  Associates  Inc.,  (301)  460-4050 
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17 

CONTRACTING  FOR  LOGISTICS 

Logistics  in  Time  Saves  a  Return  to  the  Prime. 


17.1  QRTECTIVES 

Contracting  for  support  is  the  principal  means  to  implement  the  government's  logistics  strategy. 
Contracting  is  done  within  the  framework  of  contract  laws  and  regulations  and  must  be  in  consonance 
with  the  acquisition  strategy  approved  by  the  milestone  decision  authority  (see  17.2.3.1).  Contracting 
is  used  to  acquire  many  or  all  of  the  following  logistics  dehverables  from  commercial  sources  during 
system  acquisition; 

•  logistics  documentation,  such  as  analyses,  plans,  designs,  and  reports; 

•  support  materials,  such  as  spare  and  repair  parts,  support  equipment  and  software;  and 

•  logistics  services  such  as  training,  component  repair,  and  "turn-key"  maintenance  and 
supply  support  of  selected  equipment  (e.g.,  training  simulators)  or  of  the  system. 

Some  of  these  deliverables  may  be  procured  under  a  separate  logistics  contract;  others  may  be  part  of 
an  overall  program  contract.  In  either  case,  the  government's  objectives  are  to  satisfy  its  logistics 
support  needs  at  a  fair  price  within  legal  and  regulatory  boundaries.  The  contract  will  provide  spe¬ 
cific  responsibilities  for  both  parties.  The  general  government  contracting  activities  are  hsted  below 
in  chronological  order: 

•  Acquisition  Strategy 

•  Acquisition  Planning 

•  Procurement  Package 

•  Solicitation  Process 

•  Proposal  Evaluation 

•  Discussions/Negotiation  and  Contract  Award 

•  Contract  Monitoring 
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17.2  BACKGROUND 


17.2.1  Acquisition  Policy,  Law,  and  Regulations 

U.S.  Government  policy  calls  for  heavy  reliance  on  private  commercial  sources  for  supplies  and 
services  (Office  of  Management  and  Budget  (OMB)  Circular  No.  A-76,  "Performance  of  Commer¬ 
cial  Activities").  The  Federal  Acquisition  Regulation  (FAR)  and  other  procurement  directives  set 
forth  rules  and  procedures  for  implementing  this  policy.  These  documents  reflect  both  the  basic  pro¬ 
curement  law,  the  Armed  Services  Procurement  Act,  and  revisions  enacted  during  the  annual  authori¬ 
zation  and  appropriation  process.  The  DoD  implements  and  expands  on  the  FAR  in  the  Defense  Fed¬ 
eral  Acquisition  Regulation  Supplement  (DFARS)  and  Service  supplements. 

17.2.2  Contracting  Authority,  Responsibility,  and  Participation 

Authority  and  responsibiUty  to  contract  for  authorized  supplies  and  services  are  vested  in  the  agency 
head  and  delegated  to  contracting  officers.  In  turn,  the  contracting  officer  is  responsible  for  ensuring 
that  all  requirements  of  the  law,  executive  orders,  regulations,  and  procedures  have  been  met  prior  to 
exercising  this  authority.  Although  contracting  officers  are  allowed  wide  latitude  in  exercising  busi¬ 
ness  judgment,  they  must  ensure  that  contractors  receive  impartial  and  equitable  treatment;  and  they 
must  elicit  and  consider  the  advice  of  specialists  in  program  management,  engineering,  logistics,  and 
other  fields  as  appropriate  (FAR  1.602-2). 

Specialists,  such  as  Logistics  Managers  (LMs),  must  be  involved  in  major  contract  events  such  as 
source  selection.  Major  contracting  activities  such  as  developing  the  acquisition  strategy  for  logistics 
are  primarily  the  responsibihty  of  the  LM.  The  LM  has  some  involvement  in  the  entire  contracting 
process  from  preparation  of  the  procurement  package  to  monitoring  contractor  perfonnance. 

17.2.3  The  Contract  Process 

The  primary  contracting  activities  for  the  LM  involvement  include:  developing  the  contracting  strat¬ 
egy,  planning  the  acquisition,  recommending  contract  method  and  type,  preparing  the  procurement 
package,  evaluating  proposals,  and  monitoring  contract  performance.  These  are  discussed  in  FAR  7, 
34,  35,  and  37.  Solicitation,  negotiation,  and  award  processes  are  the  responsibility  of  the  contracting 
officer,  with  assistance  as  required  from  specialists  such  as  the  LM  (Figure  17-2).  The  LM  should 
become  familiar  with  his  responsibihties  for  these  contract  events  as  they  relate  to  contracting  for 
support.  Figures  17-1  and  17-2  display  a  generic  chronology  of  contract  events.  These  time  frames 
are  representative  contract  lead  times  under  the  Competition  in  Contracting  Act  of  1984. 

17.2.3.1  Acquisition  Strategy.  The  LM's  acquisition  strategy  should  permit  prepriced  competitive 
contracts.  Other  strategy  considerations  include  appropriate  implementation  of  warranties,  breakout, 
and  the  consolidation  of  spare  parts  requirements  (initial,  foUow-on,  and  replenishment).  The  logis¬ 
tics  contract  strategy  must  be  compatible  with  the  overall  program  acquisition  strategy. 
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Figure  17-1:  Procurement  Action  Cycles  (Full  and  Open  Competition) 
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Figure  17-2;  Support  Contract  Cycle  (Sole  Source) 


17.2.3.2  Acquisition  Planning.  In  planning  the  acquisition  of  logistics  data,  materials,  or  services,  the 
LM  should  work  with  (or  support)  the  government  team.  They  are  responsible  for  significant  aspects 
of  the  acquisition,  such  as  contracting,  financial,  and  technical,  which  are  needed  to  create  an  acquisi¬ 
tion  plan  (FAR  7. 105).  A  wide  selection  of  contract  types  is  available,  and  provides  flexibility  in  ac¬ 
quiring  the  needed  logistics  resources.  These  contracts  vary  according  to  the  degree  and  timing  of  re¬ 
sponsibility  (risk)  assumed  by  the  contractor  for  cost  and  performance  and  the  amount  and  nature  of 
profit  incentive. 

Contract  types  are  grouped  into  two  broad  categories:  fixed-price  contracts  and  cost-reimbursement 
contracts.  Specific  contract  types  range  firom  firm-fixed-price,  where  the  contractor  is  fully  responsible 
for  performance,  cost,  and  profit  (or  loss),  to  Cost-Plus-Fixed-Fee  (CPFF),  in  which  the  contractor  has 
minimal  responsibilities  for  performance  and  cost  but  receives  a  negotiated  fee  (FAR  16).  In  Cost- 
Plus-Incentive-Fee  (CPIF)  contracts,  the  government  still  bears  the  major  risk;  however,  the  contrac¬ 
tor's  fee,  ie.,  profit,  will  vary  based  upon  the  achievement  of  those  objectives  that  were  incentivized  in 
the  contract. 

17.2.3.3  The  Procurement  Package.  The  Procurement  Package  enconpasses  most  of  the  information 
the  contracting  officer  needs  in  order  to  prepare  a  solicitation  as  prescribed  by  “Part  I  -  The  Schedule 
of  the  Uniform  Contract  Format”  (FAR  14.201-2).  It  provides  technical  and  management  information 
including  the  range  and  depth  of  data,  materials,  and  services  to  be  acquired.  A  timely  and  comprehen¬ 
sive  statement  is  required  for  each  acquisition  involving  equipment  or  processes  needing  future  support 
materials,  services,  or  data  MIL-HDBK-245B,  “Preparation  of  the  Statement  of  Work  (SOW),”  pro¬ 
vides  specific  guidance  on  how  to  identify  and  present  information  on  logistics  deliverables  in  a  format 
consistent  with  life-cycle  phase  requirements. 

The  LM  should  be  concerned  with  each  part  of  the  Procurement  Package  because  logistics  require¬ 
ments  are  normally  spread  throughout  the  document.  Care  should  be  taken  in  selecting  and  describing 
related  deliverables.  Plans,  drawings,  specifications,  standards,  and  purchase  descriptions  should  be 
selectively  applied  and  tailored  to  the  particular  application  in  the  SOW.  Heavy  reliance  must  be 
placed  on  commercial  and/or  performance  specifications  since  many  military  standards,  which  provided 
guidance  and  requirements  related  to  logistics,  were  canceled  as  a  result  of  the  Federal  Acquisition 
Streamlining  Act  of  1995. 

After  reviewing  the  available  standards  bearing  on  a  given  topic,  select  the  fewest  number  of  standards 
that  encompass  the  desired  range  and  depth  of  logistics  tasking  in  such  areas  as  planning,  supply,  man¬ 
power,  personneL  and  training.  Specific  applications  should  be  tailored  to  meet  program  needs  by  se¬ 
lecting  or  modifying  standard  Data  Item  Descrqjtions  (DIDs).  The  procurement  package  should  in¬ 
clude: 


•  guidance  to  the  contractor  about  the  government's  baseline  of  logistics  -  objectives,  re¬ 
quirements,  importance  relative  to  other  program  objectives,  concepts,  assumptions,  con¬ 
straints,  and  priorities; 
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•  specific  logistics  tasks  to  be  perfonned  by  the  contractor,  such  as  logistics  analyses,  logis¬ 
tics  alternatives  evaluations,  preparation  of  plans  and  concepts,  training  courses,  spares  and 
repair  parts,  technical  data,  etc.;  and 

•  incentives  aimed  at  achieving  the  desired  balance  between  logistics  and  other  performance 
capabilities. 

The  terms  used  must  be  understandable  and  consistent  with  standard  contractual  clauses.  Buzz 
words,”  terms  with  multiple  meanings,  conflicting  or  unclear  terms,  and  symbols  must  be  avoided. 

17  2.3.4  Proposals  The  LM  identifies  and  defines  what  logistics  Considerations  should  be 

addressed  in  the  ofiFeror's  proposals  and  helps  to  determine  the  relative  importance  (weight)  of  evalua¬ 
tion  factors  such  as  understanding  of  the  problem,  technical  approach,  "other  technical  factors,  experi¬ 
ence,  and  cost.  Other  technical  factors  should  provide  measurable  and  meaningful  criteria  related  to 
the  specific  logistics  support  requirements  of  the  proposed  system.  These  logistics  considerations  are 
also  incorporated  in  the  overaU  Source  Seleetion  Plan  (SSP)  which  contains  the  evaluation  factors  and 
weights  for  each  factor.  These  must  be  on  record  with  the  contracting  officer  and  ineorporated  into  the 
Request  for  Proposal  (RFP)  prior  to  RFP  release.  In  preparing  for  evaluation  working  group  meetings, 
the  LM  should  independently  evaluate  all  technical  proposal  items  related  to  logistics  in  order  to  con¬ 
tribute  meaningful  leadership  in  the  diseussions  leading  to  source  selection. 

17.2.3.5  Contract  Mnnitorinp,  A  comprehensive  contract  file  is  a  useful  management  tool  This  file 
should  include  aU  proeurement  and  administrative  contract  modifications,  which  are  referred  to  as  P 
mods"  and  "A  mods."  Data  in  the  eontract  file  directly  relate  actual  performance  to  actual  cost  and, 
when  automated,  do  so  in  a  timely  manner.  During  the  performance  period,  this  data  should  be  used  to 
rapidly  identify,  examine,  and  resolve  logistics  problems  that  arise. 

17.2.4  Contracting  Methods 

The  Competition  in  Contracting  Act  of  1984  requires  agencies  that  are  conducting  procurements  for 
goods  and  services  to  obtain  "full  and  open  eompetition"  through  the  maximum  use  of  "competitive 
procedures."  This  means  that  all  responsible  sourees  are  encouraged  to  submit  sealed  bids  or  conpeti- 
tive  proposals,  depending  on  what  is  required  by  the  solicitation. 

There  are  two  primary  differences  between  the  conpetitive  procedures,  which  are  known  as  sealed 
bids,  and  conpetitive  proposals.  The  first  difference  relates  to  award  factors.  When  sealed  bids  are 
used,  the  award  will  be  based  solely  on  price  and  other  price-related  factors.  In  contrast,  conpetitive 
proposals  permit  consideration  of  other  factors,  such  as  technical  merit,  that  go  beyond  cost  in  meeting 
the  government's  need. 

The  second  difference  involves  the  permissibility  of  negotiations  to  arrive  at  the  business  agreement. 
With  sealed  bids,  discussions  are  not  permitted,  other  than  those  needed  for  purposes  of  minor  clarifi¬ 
cations.  Conpetitive  proposals,  however,  do  permit  discussions  and  afford  the  offerors  an  opportunity 
to  revise  their  offers  subsequent  to  discussions.  In  context,  "bargaining"  refers  to  discussion,  persua¬ 
sion,  and  alteration  of  initial  assunptions  and  positions.  The  give-and-take  may  apply  to  price,  sched- 
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ule,  technical  requirements,  and  other  terms  of  the  proposed  contracts.  The  use  of  "other  than  com¬ 
petitive  procedures,”  (sole  source  negotiations)  is  only  authorized  when  the  circumstances  of  the  ac¬ 
quisition  meet  the  criteria  of  one  of  seven  identified  exceptions  (FAR  6). 

173  MANAGEMENT  ISSUES 

173.1  Data 

In  the  past,  a  major  data  problem  has  been  the  incon5)lete  identification  of  data  requirements  and  the 
lack  of  en5)hasis  on  procedures  that  ensure  legible,  conqjlete,  and  correct  drawing  practices.  Contract 
requirements  for  a  Technical  Data  Package  (TDP)  must  be  traceable  to  the  government  configuration 
management  plan,  which,  in  turn,  must  inqjlement  the  acquisition  strategy  approved  by  the  Milestone 
Decision  Authority  (MDA). 

It  is  not  easy  to  verify  that  the  delivered  product  drawings  and  associated  lists  (e.g.,  specifications; 
software  documentation;  preservation,  packaging,  packing,  and  marking  data;  test  requirements  data; 
and  quality  assurance  provisions)  will  satisfy  all  needs  for  conqjetitive  procurement.  Personnel  prepar¬ 
ing  the  data  and  those  reviewing  it  should  be  able  to  determine  whether  they  could  manufacture  the 
documented  component  "without  additional  design  engineering  or  recourse  to  the  original  design  ac¬ 
tivity."  One  review  approach  is  to  award  an  independent  verification  contract  to  a  manufacturing  or 
production  engineering  firm  that  has  relevant  hands-on  manufacturing  experience.  The  following 
guidelines  are  offered  for  developing  technical  data  packages: 

•  Determine  the  level  of  specificity  required  for  procurement  purposes. 

•  Ensure  that  the  parts  descriptions  and  drawings  are  available  so  other  participants  in  the 
acquisition  understand  what  is  being  bought. 

•  Establish  prices  and  options  for  data  delivery  only  after  the  design  is  stable  enough  to  make 
it  useful 

•  Obtain  technical  data  on  a  phased  schedule  to  permit  breakout  of  vendor  components  for 
future  competitive  acquisitions. 

•  Inspect  and  validate  the  completeness,  accuracy,  and  adequacy  of  data  promptly  after  its 
receipt. 

•  Consult  with  the  contracting  officer  to  ensure  that  the  current  regulations  concerning  data 
rights  and  data  restrictions  (FAR  27)  are  incorporated  in  the  solicitation. 

•  Technical  personnel  should  review  proprietary  or  other  restrictive  markings  on  drawings 
and,  when  appropriate,  request  the  contracting  officer  to  obtain  a  written  justification  fi-om 
the  contractor  for  the  restrictive  marking 
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173^  Spares  and  Breakout 

Decisions  affecting  spares  must  be  made  very  early  in  the  life  cycle  of  a  system.  As  the  program 
evolves,  the  IM  must  issue  provisioning  technical  documentation  guidance  via  the  contract.  This  guid¬ 
ance  should  include  milestones  and  feedback  reporting  to  ensure  that  program-unique  materials  are 
pron?)tly  ordered.  The  LM  must  also  ensure  that  follow-on  spare  and  repair  parts  are  obtained  in  a 
cost-effective  manner.  Relying  on  the  original  prime  contractor  for  follow-on  support  material  entails 
risks  in  the  areas  of  cost  and  availability  of  needed  spare  and  repair  parts  —  especially  during  the  post¬ 
production  support  period  (see  Chapter  27).  The  LM  should  consider  obtaining  technical  data,  draw¬ 
ings,  tooling,  etc.,  to  enable  the  Service  to  compete  for  follow-on  logistics  support.  The  cost  of  ob- 
taini’ng  this  capability  must  be  weighed  against  the  potential  benefits  of  competition,  particularly  during 
an  extended  postproduction  period.  FAR,  Part  7,  requires  the  inclusion  of  detailed  conponent  break¬ 
out  plans  in  the  acquisition  plan.  In  summary,  to  develop  and  deliver  an  effective  spares  package  to 
future  users,  the  LM  should: 

•  ensure  the  timely  and  accurate  assignment  of  procurement  source  codes  (e.g.,  prime  con¬ 
tractor,  vendor,  field  manufacture,  etc.)  and  challenge  data  rights  and  restrictive  markings; 

•  require  contractors  to  identify  actual  manufacturers; 

•  screen  contractor-recommended  parts  lists  to  make  full  use  of  DoD  and  General  Services 
Administration  (GSA)  supply  systems; 

•  make  sure  parts  already  available  in  DoD  and  GSA  supply  systems  are  directly  bought, 

•  order  optimum  quantities  where  significant  savings  can  be  obtained; 

•  base  estimated  unit  prices  on  anticipated  buy  quantities  rather  than  a  single  item;  (Provi¬ 
sioning  prices,  i.e.,  prices  established  during  the  provisioning  process,  should  not  be  used  as 
the  basis  for  determining  the  reasonableness  of  the  price  of  future  buys.  Procurement  his¬ 
tory  records  should  identify  provisioning  prices  as  such.) 

•  consider  Spares  Acquisition  Integrated  with  Production  (SAIP)  where  the  government 
combines  spare  parts  orders  with  planned  production; 

•  encourage  muUi-year  procurement  of  replenishment  spares  that  are  sensitive  to  quantity 
and  fi:ont-end  investment  costs; 

•  ensure  that  all  spare  parts  requirements  (initial  or  replenishment)  are  combined  to  the 
maximum  extent  possible  to  achieve  the  savings  of  larger  quantities;  (Buying  offices  should 
alert  users  when  firequent  purchases  of  the  same  part  are  causing  higher  costs.) 

•  ensure  realistic  breakout  and  competition  goals  by  considering  savings  potential  and  avail¬ 
ability  of  procurement  specialists  to  conduct  competitions  and  breakout  actions;  and 

•  ensure  that  tradeoffs  are  made  between  inventory  carrying  costs  and  marketplace  quantity 
discounts. 
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1733  Contracts  and  Pricing 

A  Program  Manager  (PM)  often  regards  logistics  contract  considerations,  such  as  identifying  logistics 
deliverables  and  creating  the  logistics  input  to  the  SOW,  as  long-term  issues  that  are  less  inportant 
than  the  immediate  problems.  As  a  result,  logistics  concerns  are  often  deferred  for  later  resolution.  A 
common  exan5)le  is  the  acquisition  of  data  needed  for  future  support.  Understandably,  the  PM  with  a 
funding  shortfall  is  more  likely  to  cut  the  long-term  logistics  requirements  fi'om  the  contract  than  items 
with  immediate  impact. 

An  OMB  review  found  that  a  large  number  of  unpriced  orders  are  backlogged  at  many  DoD  activities. 
The  time  required  for  audit,  cost  or  price  analysis,  and  negotiation  of  a  contractor's  proposal  may  relate 
to  the  number  of  cost  elements  to  be  negotiated.  Solutions  have  included  reducing  the  number  of  cost 
elements  to  be  analyzed  as  well  as  avoiding  the  use  of  Basic  Ordering  Agreements  (BOAs)  and  the  or¬ 
dering  (provisioning)  clause  for  the  large  amounts  of  data  and  spares  that  can  be  firm-fixed-priced  at 
the  time  the  order  is  placed.  Another  solution  is  the  use  of  forward  pricing  arrangements.  These  pro¬ 
vide  for  advance  negotiation  of  direct  and  indirect  cost  factors  that  can  then  be  used  for  a  mutually 
agreed  upon  time.  The  re-negotiated  logistics  cost  factors  facilitate  efficient  pricing  of  a  contractor's 
proposal  by  providing  more  time  to  analyze  direct  costs.  These  factors  can  be  routinely  used  by  less 
experienced  buyers  and  are  easily  adapted  to  a  conputerized  system  Increased  emphasis  on  negotiat¬ 
ing  forward-pricing  arrangements  should  result  in  a  decrease  in  the  number  of  outstanding  unpriced 
orders.  Goals  should  be  set  and  monitored  for  the  control  of  unpriced  orders. 

173.4  Government  Furnished  Property  and  Other  Promises 

The  government's  failure  to  provide  promised  Government  Furnished  Material  (GFM)  in  a  timely  man¬ 
ner  and  in  suitable  condition  may  create  a  government  liability  for  subsequent  cost  and  schedule  in¬ 
creases  (FAR  52.245-2).  Therefore,  the  LM  should  only  identify  GFM  that  the  government  can  pro¬ 
vide  in  a  timely  manner  and  in  a  condition  suitable  for  use.  If  appropriate,  the  Contracting  Office  may 
allow  the  contractor  to  utilize  MIL-STRIP  procedures  in  obtaining  the  required  GFM  (FAR51). 

173.5  Unrealistic  Delivery  or  Performance  Schedules 

The  government  is  capable  of  creating  such  pressure  in  negotiated  contracts  that  a  contractor  may  feel 
obligated  to  agree  to  unachievable  terms.  Subsequently,  the  contractor  may  seek  and  receive  relief 
fi'om  unreasonable  requirements.  Therefore,  LMs  should  avoid  issuing  requirements  on  an  urgent  basis 
or  with  unrealistic  delivery  or  performance  schedules  since  it  generally  restricts  competition  and  in¬ 
creases  costs. 

173.6  Incentives 

Incentive  mechanisms  in  contracts  are  used  to  motivate  contractors  to  exceed  predetermined  thresholds 
for  performance,  delivery,  and  reliability  and  maintainability  (R&M),  etc.  Incentives  provide  this  moti¬ 
vation  by  establishing  a  relationship  between  the  amount  of  fee  payable  and  the  results  achieved.  When 
predetermined  measurable  incentives  on  delivery  or  technical  performances  are  included,  fee  increases 
are  provided  for  achievement  that  exceeds  the  targets;  and  fee  reductions  are  made  when  targets  are 
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not  met.  Incentive  contracts  are  addressed  in  FAR  17.4  and  in  a  joint  DoD/NASA  Incentive  Con¬ 
tracting  Guide.  Logistics  incentives  should  be  designed  to  address  one  or  more  of  the  following  condi¬ 
tions: 


•  Designs  that  tend  to  reduce  logistics  costs  during  the  operational  phase  of  the  life  cycle  (in¬ 
creased  use  of  standard  conqxjnents,  reduced  trouble-shooting  time,  etc.); 

•  Logistics  system  accelerated  delivery  (all  elements)  commensurate  with  accelerated  pro¬ 
gram  delivery;  and/or 

•  R&M  thresholds  exceeded.  (Incentives  are  established  for  significant  goals  that  wiU  yield 
increased  combat  effectiveness  or  decreased  ownership  costs.) 

173.7  Warranties 

This  topic  is  covered  in  Chapter  19,  Section  19. 

17.4  RISK  AVOroANCE 

The  major  risk  area  in  logistics  contracting,  in  terms  of  inpact  and  the  probability  of  its  occurrence,  is 
the  failure  to  properly  contract  for  data,  materials,  and  services.  Included  are  failures  involving  con¬ 
tractual  promises  by  the  government  to  furnish  material  and  services  and  the  mposition  of  unrealistic 
delivery  or  performance  schedules.  Inpacts  may  include  degraded  support  and  readiness,  cost  growth, 
and  loss  of  the  taxpayers'  good  will  and  confidence.  Contracting  for  support  entails  many  areas  of  risk, 
which  the  PM  must  control  Permanent  solutions  to  these  problems  are  elusive  unless  management’s 
attention  is  sustained  at  all  levels.  Without  such  attention,  we  will  only  rpeat  the  mistakes  of  the  past 
—  a  flurry  of  activity  (amounting  to  overkill)  dying  out  without  producing  meaningful  or  lasting  im¬ 
provements. 

Toward  the  goal  of  inproving  logistics  procurement  practices,  the  Office  of  Federal  Procurement  Pol¬ 
icy  issued  a  rqiort  that  offers  more  than  100  recommendations  and  suggestions  aimed  at  avoiding  well- 
known  risk  areas  (Reference  2).  Those  most  applicable  to  executive  and  working-level  LMs  are  in¬ 
cluded  in  the  guidance  given  in  Section  17.3,  ‘Management  Issues.”  They  may  be  used  as  a  checklist, 
either  to  guide  hands-on  managerial  efforts  or  to  review  the  work  of  matrix  personnel  to  ensure  the 
price  consciousness  of  their  efforts. 

17.5  CONTRACTING  TOOLS 

•  LOGPARS  (The  Logistics  Planning  and  Requirements  System).  This  system  was  developed 
for  use  on  a  desktop  PC.  It  is  an  expert  system,  which  leads  a  LM  through  the  thought  process 
necessary  to  plan  and  execute  a  logistics  program.  The  latest  version  (June  1997)  includes  im¬ 
portant  acquisition  reform  emphases.  This  tool  is  available  on  the  internet  at: 

http://www.logpars.army.mil/alc/logpars/logpars.htm 
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The  system  was  developed  by  USAMC  Logistics  Support  Activity,  Redstone  Arsenal,  Ala¬ 
bama,  and  incorporates  the  required  policy,  lessons  learned,  and  expert’s  experience  to  produce 
critical  logistics  program  documentation.  The  systematic,  user-fiiendly  approach  that  LOG- 
PARS  offers  ensures  all  considerations  are  addressed,  encourages  conq)liance  with  existing 
policy,  and  eliminates  potential  for  contracting  redundant  information 

•  Turbo  Streamliner.  This  tool  was  developed  and  is  maintained  by  the  Navy  Acquisition  Re¬ 
form  Office  and  is  available  on  the  Internet  at: 

http://www.acq-refnavy.mil/turbo/ 

It  provides  a  checklist  of  Acquisition  Reform  topics,  an  RFP  checklist,  guidelines  for  reporting 
metrics,  lessons  learned,  and  guidelines  for  streamlining  an  RFP.  It  also  provides  a  guide  for  as¬ 
sessing  the  effectiveness  of  the  Acquisition  Reform  initiatives  in  the  contracts  awarded,  based 
on  RFPs  evaluated  during  Phase  I  of  the  RFP  Benchmarking  effort. 

17.6  SUMMARY 

•  Participation  in  the  contracting  process  is  part  of  the  LM's  job. 

•  Contract  knowledge,  initiative,  and  determination  are  essential  in  managing  logistics  pro¬ 
grams. 

•  Logistics  program  success  is  a  direct  reflection  of  contract  success. 
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INFORMATION  TECHNOLOGY’ 


JCALS  Goal  Statement:  “Provide  timely,  authorized  access  to 
accurate,  current  data  anywhere  in  the  system  regardless  of 
where  it  is  stored,  how  it  is  formatted,  or  how  it  is  accessed.  ” 

Computer  Sciences  Corporation,  in 
briefing  to  DSMC  on  3  April  1997. 


18.1  INTRODUCTION  TO  INFORMATION  TECHNOLOGY  DATA 

18.1.1  Definitions 

•  Information  Technology:  any  equipment  or  interconnected  system  or  subsys¬ 

tem  of  equipment,  that  is  used  in  the  automatic  acquisition,  storage,  manipulation, 
management,  movement,  control,  display,  switching,  interchange,  transmission,  or 
reception  of  data  or  information  by  the  executive  agency  ...  includes  computers, 
ancillary  equipment,  software,  firmware  and  similar  procedures,  services  (including 
support  services),  and  related  resources.”  (PL  104-106,  Sec.  5002) 

•  Tnfnrmatinn  Technology  Architecture:  “...  an  integrated  firamework  for  evolving  or 
maintaining  existing  information  technology  and  acquiring  new  information  tech¬ 
nology  to  achieve  the  agency’s  strategic  goals  and  information  resources  manage¬ 
ment  goals.”  (PL  104-106,  Sec.  5125) 

•  Automated  Information  System  (AIS):  A  combination  of  computer  hardware  and 
software,  data,  or  telecommunications  that  performs  functions  such  as  collecting, 
processing,  transmitting,  and  displaying  information.  Hardware  and  software 
computer  resources  are  excluded  if  they  are  physically  part  of,  dedicated  to,  or  es¬ 
sential  in  real  time  to  the  mission  performance  of  weapon  systems.  (DoD  5(X)0. 1 , 
paragraph  C.4.) 

This  Chapter  gives  emphasis  to  logistics  information  technology  in  the  context  of  digital 
data,  i.e.,  digitally  developed  (digitized)  data  that  may  be  accessed  or  delivered,  indexed, 
and  maintained  using  automation  techniques.  Logistics  digital  information  may  take  the 
form  of  technical  data,  drawings,  schedules,  or  general  reports. 


‘  Much  of  the  material  in  this  Chapter  is  drawn  from  the  DSMC  pubUshed  report  of  the  Military  Research  Fellows,  DSMC,  1995-1996, 
Navigating  The  Digital  Environment:  A  Program  Manager’s  Perspective,  by  P.  F.  Cromar,  A.  G.  Wiley,  and  R.  L.  Tremaine. 
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18.1.2  Application 

Program  Managers  (PMs)  and  their  systems  engineering  staffs  (including  logisticians) 
should  consider  how  to  apply  and  exploit  the  digital  information  environment.  In  this  re¬ 
gard,  Cromar,  Whey,  and  Tremaine  (noted  in  footnote  1)  offered  the  concept  of  an  Acqui¬ 
sition  Program’s  Digital  Environment  (APDE)  to  describe  a  cross-functional,  integrated 
digital  information  infrastructure  that  supports  a  DoD  acquisition  program.  The  APDE 
lioks  the  entire  acquisition  program  team,  including  not  only  the  PM  office  and  prime 
contractor  personnel  but  also  subcontractors,  vendors,  suppliers,  support  agencies,  and 
end  users.  An  APDE  can  take  many  forms,  depending  largely  upon  the  extent  to  which  an 
acquisition  program  is  able  to  exploit  digital  information  technology  and  integrate  proc¬ 
esses  efficiently  and  effectively.  If  increased  productivity  and  substantive  cost  savings 
through  process  improvement  and  reengineering  are  program  objectives,  evidence  shows 
that  such  a  digital  environment  is  a  key  enabler  and  a  necessary  precondition  for  success. 

18.1.3  Digital  Fog 

A  “fog”  can  easily  screen  the  PM’s  view  of  the  digital  information  environment.  The  DoD 
and  industry  have  been  incorporating  many  digital  initiatives  for  streamlining,  promoting 
greater  competition,  and  improving  business  practices  for  the  last  decade  with  a  confusing 
number  of  digital  directives,  digital  standards,  and  digital  strategies.  Integrating  digital 
information  environments  is  relatively  recent  and  revolutionary.  Notwithstanding,  there  is 
no  single  organization  in  the  acquisition  community  responsible  for  developing  and  main¬ 
taining  a  roadmap  that  would  help  PMs  navigate  their  respective  digital  domains.  The  re¬ 
searchers  were  told  by  one  PM,  ‘The  lack  of  definitive  guidance  and  a  prescribed  way  to 
do  it  are  the  biggest  blocks.  We  are  having  to  feel  our  way  through,  and  we  may  be  going 
down  a  dead-end  path.”  Not  surprisingly,  the  en^loyment  of  integrated  digital  environ¬ 
ments  within  PM  offices  has  been  uneven.  The  creation  of  one  might  be  constrained  both 
by  the  PM’s  vision  and  the  program  budget,  even  though  the  PM  may  recognize  “infor¬ 
mation  technology  must  be  viewed  as  an  investment.” 

Even  though  available  guidance  on  how  to  best  exploit  the  digital  environment  to  support 
their  strategy  has  not  yet  materialized,  a  few  program  offices  have  taken  advantage  of  the 
enabling  and  evolving  digital  resources.  On  the  other  hand,  more  and  more  industry  part¬ 
ners  are  designing,  manufacturing,  testing,  and  supporting  defense  systems  within  digital 
environments,  developing  new  systems  digitally,  and  creating  dynamic  digital  enterprises. 
Being  at  the  center  of  their  system  enterprise,  the  government  PM  must  understand  an  in¬ 
tegrated  digital  environment  before  ever  hoping  to  properly  exploit  its  advantages. 

Since  1988,  the  DoD  has  spent  between  4  and  5  billion  dollars  fueling  the  many  compo¬ 
nents  of  an  Integrated  Data  Environment  (IDE)  in  an  attempt  to  accommodate  the  deliv¬ 
ery  of  digital  product  data  to  the  weapon  system  sustainment  communities.  Despite 
DoD’s  efforts,  however,  an  IDE’s  benefits  to  the  acquisition  community  are  not  always 
well  known,  well  understood,  or  well  communicated.  In  some  cases,  promises  of  signifi¬ 
cant  overall  cost  reductions  are  not  even  believed.  Most  DoD  training  courses  are 
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targeted  toward  logisticians,  contracting  officers,  engineers,  and  data  managers.  They  do 
not  focus  on  PMs  or  on  integrating  processes.  The  basic  construction  of  a  robust  IDE 
may  not  be  inexpensive;  this  compounds  the  problem  and  raises  the  issue  of  who  is  re¬ 
sponsible  for  payment.  In  light  of  shrinking  defense  budgets,  PMs  may  be  left  with  doing 
everything  they  can  to  simply  sustain  their  program  and  continue  to  satisfy  the  user’s 
needs.  Since  1994,  some  major  weapon  programs  have  had  to  be  realigned  annually  be¬ 
cause  of  congressionaUy  directed  funding  reductions.  It  is  easy  to  understand  why  re¬ 
sources  necessary  for  a  robust  digital  environment  may  be  sacrificed  as  PMs  may  not  eas¬ 
ily  envision  a  return  on  investment  during  their  watch.  Clearly,  the  PM  needs  to  know 
what  is  in^ortant  and  what  works  today:  (1)  before  committing  any  program  dollars  for 
an  APDE  and  (2)  before  the  DoD  can  expect  the  PM  to  “buy-in”  to  the  proposed  merits 
of  an  APDE. 

18.2  THE  DIGIT AI.  ENVIRONMENT 
18.2.1  A  Short  History 

The  current  DoD  effort  to  move  acquisition  and  logistics  into  the  digital  age  began  in  late 
1984  with  the  enactment  of  Public  Law  98-525.  An  outgrowth  of  this  law  was  an  Insti¬ 
tute  for  Defense  Analysis  (IDA)  study  released  in  June  of  1985,  which  recommended  a 
strategy  and  master  plan  for  Con^uter  Aided  Logistics  Support  (CALS)  for  the  manage¬ 
ment  of  technical  data.  This  led  to  the  establishment  of  the  DoD  CALS  Office  (now  Con¬ 
tinuous  Acquisition  Life-Cycle  Support  Office).  The  role  of  CALS  grew  in  the  late  80s 
and  early  90s.  During  this  period.  Electronic  Commerce/Electronic  Data  Interchange 
(EC/EDI)  emerged  to  enable  computer-to-conputer  exchange  of  business  information.  It 
provided  a  standardized  means  to  integrate  business  functions,  enable  process  improve¬ 
ments,  and  estabUsh  a  basis  for  virtual  enterprises.  In  1994,  EC/EDI  responsibilities  were 
moved  from  the  CALS  Office  to  an  Electronic  Commerce  (EC)  Office,  established  under 
the  Deputy  Under  Secretary  of  Defense  (Acquisition  Reform)  (DUSD(AR)).  While  sup¬ 
porting  DoD- wide  efforts  to  enable  the  exchange  of  a  variety  of  business  processes 
through  EDI,  the  primary  responsibility  of  the  EC  Office  is  to  manage  the  implementation 
of  EDI-based  contracting.  See  Figure  18-1. 

Recognizing  the  fact  that  the  CALS  effort  started  in  the  logistics  community  and  organi¬ 
zationally  remains  under  logistics  makes  it  exceptionally  hard  to  overcome  the  stereotype 
that  CALS  is  a  purely  logistics  program.  Interviews  by  researchers  Cromar,  Whey,  and 
Tremaine  (noted  in  footnote  1)  showed  that  several  senior  DoD  officials  believe  that  the 
CALS  current  efforts  concentrate  primarily  on  logistics  and  sustainment  activities.  Simi¬ 
larly,  EC  Office  efforts  have  been  largely  directed  at  the  contracting  community  and  small 
procurements,  despite  significant  support  to  other  EDI-related  business  processes.  While 
both  the  CALS  and  EC/EDI  offices  are  working  to  advance  the  acquisition  community, 
the  perception  in  the  field  is  that  they  are  separate,  functionally  based  initiatives  that  do 
not  specifically  focus  on  or  address  the  information  and  business  needs  of  the  PM. 
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Figure  18-1:  Major  DoD  Organizations  Involved  in  the  Digital  Environment 


18.2.2  Major  Players 

While  DoD  would  like  to  present  a  “single  face”  to  industry,  the  Services,  and  PM  offices, 
there  are  a  variety  of  organizations  involved  in  different  aspects  of  the  digital  environment. 
A  digital  environment  that  supports  the  acquisition  community  must  interconnect  with  the 
Defense  Information  Infrastructure  (DII),  which,  in  turn,  is  an  integral  part  of  the  National 
Information  Infrastructure  (Nil).  Agencies,  apart  from  DoD,  such  as  NASA,  Department 
of  Commerce,  Department  of  Treasury,  and  the  Department  of  Energy,  are  also  affected. 
Business  processes  and  standards  clearly  have  global  applications.  This  section  identifies 
some  of  the  major  players  involved  in  aspects  of  the  digital  environment  and  summarizes 
their  functions,  particularly  as  they  impact  the  acquisition  community.  WTiile  many  of 
these  organizations  will  not  directly  affect  PM  offices,  it  is  useful  to  understand  their  areas 
of  focus  and  the  roles  they  play. 

1 8.2.2. 1  DoD  CALS  Office.  This  office  is  under  the  Deputy  Under  Secretary  of  Defense 
(Logistics)  (DUSD(L))  and  is  responsible  for  leading  the  DoD  CALS  effort.  The  CALS 
Office  responsibilities  include: 

•  Coordinating  within  OSD  to  define  the  IDE  for  business  and  technical  information 
used  for  system  acquisition  and  life-cycle  support.  (The  IDE  will  be  congruous 
with  industry  practices  and  the  overarching  DoD  information  infrastructure  being 
developed  by  the  Defense  Information  Systems  Agency  (DISA)); 

•  coordinating  the  IDE  framework  within  the  DoD  and  ensuring  integration  of  those 
requirements  into  DoD  programs  and  processes;  and 
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•  participating  with  other  government  departments  in  an  industry  outreach  program. 

(Through  that  program,  the  CALS  Office  promotes  a  commonly  shared  informa¬ 
tion  framework,  compatible  information  infrastructures,  and  similarity  of  acquisi¬ 
tion  practices.) 

18.2.2.2  DoD  Electronic  Commerce  tECl  Office.  This  office  is  responsible  for  facilitating 
the  in[^)lementation  of  EC/EDI  across  aU  functional  lines  within  DoD.  It  also  developed 
the  Introduction  to  Department  of  Defense  Electronic  Commerce:  A  Handbook  for  Busi¬ 
ness,  Version  2,  June  1996,  which  is  a  usefiil  source  of  EC/EDI  information.  To  date,  the 
primary  focus  of  the  DoD  EC  Office  has  been  to  manage  the  implementation  of  EDI-based  con¬ 
tracting  systems  within  244  DoD  installations. 

18.2.2.3  Director.  Defense  Procurement.  As  a  Principle  Deputy  to  the  Under  Secretary 
of  Defense  for  Acquisition  and  Technology  (USD(A&T)),  the  Office  of  the  Director,  De¬ 
fense  Procurement,  develops,  interprets,  and  publishes  procurement  policy  for  DoD.  The 
Office  of  the  Director  also  establishes  requirements  and  guidelines  that  regulate  the  ex¬ 
ploitation  of  digital  environments  and  plays  an  integral  role  in  DoD  business  process  im¬ 
provement  initiatives.  Defense  Procurement  sets  policy  for  government  rights  to  technical 
data  and  develops  standardized  procurement  data  definitions  and  a  standard  procurement 
process. 

18.2.2.4  Defense  Information  Systems  Agency  rPISA).  Under  the  auspices  of  the  Assis¬ 
tant  Secretary  of  Defense  (Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance  and  Reconnaissance),  DISA  is  responsible  for  promulgation  of  standards  and 
primary  support  of  the  DII.  With  respect  to  the  development  of  a  digital  environment, 
DISA’s  role  is  to  develop  the  computer  systems  architecture  in  close  coordination  with  the 
Defense  Information  Systems  Agency  (DISA);  the  goal  is  to  have  it  fully  integrated  with 
system  migration  planning  and  to  be  ultimately  realized  via  the  DII.  The  objective  of  the 
architecture  is  to  completely  describe  the  communications  and  computer  system  infra¬ 
structure  necessary  to  support  the  IDE.  Another  objective  is  to  develop  the  plan  to  effi¬ 
ciently  migrate  both  the  CALS  flagship  systems  and  the  remainder  of  the  DoD  computer 
systems  infrastructure  that  supports  the  weapon  system  life  cycle  to  an  IDE  state.  The 
computer  systems  architecture  will  include  a  systems  specification  that  identifies  the  in¬ 
terfaces  and  performance  standards  necessary  to  meet  the  functional  requirements  of  the 
weapon  system  support  community. 

The  CALS  Digital  Standards  Office  at  DISA  is  charged  with  overseeing  CALS  standards 
activities.  DISA  is  also  responsible  for  providing  information  pertaining  to  the  testing  and 
certification  of  Value  Added  Networks  (VAN),  which  support  the  DoD  EDI  effort. 

18.2.2.5  Other  Orpanizations.  Other  organizations  involved  in  different  aspects  of  the 
digital  environment  include  the:  (Functions  of  these  organizations  are  outlined  in  Section 
18.7,  reference  1,  of  this  Chapter.) 

•  Defense  Acquisition  University/Defense  Systems  Management  College, 
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•  National  Institute  of  Standards  and  Technology, 

•  Industry  Steering  Group,  and 

•  Electronic  Commerce  Resource  Center. 

18.2.3  Definitions  and  Terms 

This  section  will  provide  an  overview  of  some  of  the  major  terms  and  initiatives  that  im¬ 
pact  PM  organizations  entering  the  digital  environment. 

18.2.3.1  Continuous  Acquisition  and  Life-Cvcle  Support  fCALSl.  CALS  is  a  DoD  and 
industry  strategy  to  accelerate  the  pace  at  which  high  quality  information  flows  within  and 
between  DoD  and  its  business  partners.  The  CALS  also  provides  an  opportunity  to  re¬ 
duce  information  management  overhead  costs.  CALS  is  a  core  strategy  to  share  inte¬ 
grated  digital  product  data  through  a  set  of  standards  to  achieve  business  efficiencies  in 
business  and  operational  mission  areas. 

The  DoD  CALS  Office  is  committed  to  incorporating  CALS  into  functional  process  im¬ 
provements.  As  DoD  attempts  to  apply  the  best  technologies,  processes,  and  standards 
for  the  development,  management,  exchange,  and  use  of  business  and  technical  informa¬ 
tion  among  and  within  governmental  and  industrial  enterprises,  an  IDE  will  be  generated. 
DoD  has  developed  a  strategic  plan  to  pursue  its  IDE  vision. 

18.2.3.2  Integrated  Data  Environment  (IDEI.  The  IDE  is  the  business  environment  cre¬ 
ated  by  the  application  of  existing  national  and  international  standards,  practices,  and 
technologies  to  automate  the  management  and  exchange  of  information.  The  vision  of  this 
DoD- wide  IDE  is  a  boundaryless  environment  where  all  data  are  accessible  to  appropri¬ 
ately  cleared  personnel  in  all  defense  enterprises.  The  IDE  enables  Integrated  Product  and 
Process  Development  (IPPD)  while  increasing  the  agility  and  decreasing  the  cycle  times  of 
the  defense  enterprise. 

The  goal  of  the  IDE  may  be  best  summarized  as  an  integrated  digital  environment  linking 
all  stakeholders  in  the  life  cycle  of  a  weapons  system  and  allowing  cross  functional  sharing 
of  data  that  is  created  once  and  used  throughout  the  entire  life  cycle  of  the  system. 

18.2.3.3  CALS/IDE  Initiatives.  As  part  of  the  CALS  strategy,  the  DoD  is  pursuing  three 
infrastructure  modernization  programs  with  the  goal  of  enabling  the  IDE.  They  are  the 
Joint  Computer-aided  Acquisition  and  Logistics  Support  (JCALS),  Joint  Engineering  Data 
Management  Information  Control  System  (JEDMICS)  and  Configuration  Management 
Information  System  (CMIS).  These  three  systems  are  being  developed  independently  to 
work  together  in  support  of  the  DoD- wide  IDE.  The  Army’s  Combat  Mobility  Systems 
(CMS)  was  the  first  program  office  to  integrate  these  systems  beginning  in  mid- 1995. 
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18.2.3.4  Electronic  Commerce  (EC).  The  term  EC  is  widely  used  by  both  the  U.S.  Gov¬ 
ernment  and  industry.  In  industry  the  term  EC  is  frequently  used  as  the  umbrella  term  to 
describe  any  digital  exchange  of  information  or  data.  Similarly,  within  DoD,  EC  is  defined 
as  the  paperless  exchange  of  business  information  using  EDI,  Electronic  Mail  (E-Mail), 
con^uter  bulletin  boards,  facsunile,  Electronic  Funds  Transfer  (EFT),  and  other  sunilar 
technologies. 

18.2.3.5  Electronic  Data  Interchange  tEDD.  EDI  is  the  computer-to-computer  exchange 
of  business  information  using  a  public  standard.  EDI  is  a  central  part  of  EC  because  it  en¬ 
ables  organizations  to  exchange  business  information  electronically  and  much  faster, 
cheaper,  and  more  accurately  than  is  possible  using  a  paper-based  system. 

Who  uses  EDI?  Currently  about  50,000  U.S.  private  sector  con^anies  such  as  Federal 
Express,  Eastman  Kodak,  American  Airlines,  Nike,  Staples,  Nations-Bank,  JC  Penney, 
and  Prudential  Insurance,  use  EDI.  EDI  is  widely  used  in  manufacturing,  shipping,  ware¬ 
housing,  utilities,  pharmaceuticals,  construction,  petroleum,  metals,  food  processing, 
banking,  insurance,  retailing,  government,  health  care,  and  textiles,  among  other  indus¬ 
tries.  According  to  a  recent  study,  the  number  of  companies  using  EDI  is  projected  to 
quadruple  within  the  next  six  years.  The  government  did  not  invent  EC/EDI;  it  is  merely 
taking  advantage  of  an  established  technology  that  has  been  widely  used  in  the  private 
sector  for  the  last  few  decades.  American  National  Standards  Institute  (ANSI)  X12  U.S. 
commercial  standards  were  developed  to  support  EDI  transactions  for  a  wide  variety  of 
industry  information  applications.  In  the  future  ANSI  XI 2  is  expected  to  graduaUy  align 
with  an  international  set  of  EDI  standards  that  are  sponsored  by  the  United  Nations  and 
known  as  Electronic  Data  Interchange  for  Administration,  Commerce,  and  Transportation 
(EDIFACT). 

18.2.3.6  Federal  Acquisition  Computer  Network  (FACNET).  In  1994,  Public  Law  103- 
355,  Federal  Acquisition  Streamlining  Act  (FAS A),  established  the  FACNET,  requiring  the 
government  to  evolve  its  acquisition  process  fi-om  one  driven  by  paperwork  to  an  expe¬ 
dited  process  based  on  EDI.  The  electronie  system  is  intended  to  provide  a  “single  faee” 
to  industry.  FASA  estabUshes  parameters  for  FACNET  users,  both  government  and  pri¬ 
vate.  These  functions  are  to  be  implemented  by  agencies  within  five  years  of  enactment  of 
the  Act.  The  government-wide  FACNET  will  be  designed  to: 

•  inform  the  public  about  Federal  contracting  opportunities, 

•  outline  the  details  of  government  solicitations, 

•  permit  electronic  submission  of  bids  and  proposals, 

•  facilitate  responses  to  questions  about  solicitations, 

•  enhance  the  quality  of  data  available  about  the  acquisition  process,  and 
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•  be  accessible  to  anyone  with  access  to  a  personal  con:q)uter  and  a  modem. 

Very  simply,  FASA  raises  the  small  purchase  threshold  to  $100,000  and  designates  this  as 
the  sunplihed  acquisition  threshold.  Procurement  activities  can  use  these  new  procedures 
when  their  activity  is  FACNET-certified.  Although  FACNET  is  currently  in  use  by  over 
200  DoD  organizations  and  installations,  there  are  other  potential  options.  With  the  ad¬ 
vent  of  the  World  Wide  Web  (WWW)  some  government  activities,  most  notably  NASA 
and  DLA,  have  chosen  to  employ  what  they  consider  to  be  more  open  solutions  than  those 
presented  by  the  FACNET. 

18.2.3.7  Contractor  Integrated  Technical  Information  Service  ('CITIS').  CITIS  is  a 
contractor-developed  and  maintained  service  to  provide  electronic  access  and/or  delivery 
of  government-procured,  contractually  required  information  (i.e..  Contract  Data  Require¬ 
ments  List  (CDRL)).  CITIS  generally  employs  electronic  networks  for  access  and  deliv¬ 
ery  of  information  and  may  include  vendor  and  supplier  data.  It  should  be  noted  that  CI¬ 
TIS  is  not  the  data  itself  or  the  database  where  it  resides;  CITIS  is  simply  the  service  or 
mechanism  that  provides  authorized  users  access  to  the  data.  CITIS  can  be  the  backbone 
of  a  Program  Management  Office  (PMO)  integrated  data  environment,  providing  signifi¬ 
cant  benefits  to  the  PMO.  It  provides  a  single  entry  point  for  authorized  government  ac¬ 
cess  to  contractor-generated  CDRL  data  and  supports  the  philosophy  of  creating  data 
once  and  using  it  many  times.  CITIS  establishes  a  set  of  core  information  functions  to  fa¬ 
cilitate  the  concept  of  “shared  data,”  and  standardizes  functional  characteristics  of  the  data 
to  facilitate  usage  by  a  wide  variety  of  different  users. 

18.2.3.8  Workflow  Manager.  A  workflow  manager  is  a  software  application  designed  to 
increase  productivity.  Using  customized  rules  or  knowledge-based  processing,  workflow 
managers  enhance  operations  by  automatically  managing: 

•  single  point  of  administration  and  maintenance; 

•  assignment  of  tasks  (personal  and  group); 

•  automatic  initiation  of  actions; 

•  coordination,  timing,  and  sequencing  of  events; 

•  notification,  suspenses,  and  e-mail-based  reminders; 

•  work  in  progress  reports  (project  and  process  status); 

•  continuous  quality  control  (data  integrity);  and 

•  data  rights  and  access. 
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A  workflow  manager  can  be  a  key  functional  component  of  an  integrated  digital  environ¬ 
ment,  helping  organizations  achieve  greater  efficiency  through  near  real  time  collaboration 
despite  geographic  and  functional  separation.  By  design,  workflow  managers  go  beyond 
e-mail  by  permitting  greater  flexibility  through  parallel  processing,  quicker  access  to  the 
correct  data  by  the  right  people  at  the  appropriate  time,  and  by  providing  a  coordinated 
and  integrated  decision-making  environment. 

18.2.4  Acquisition  Program’s  Digital  Environment  (APDE) 

The  researchers,  Cromar,  Wiley,  and  Tremaine  (noted  in  footnote  1)  developed  the  con¬ 
cept  of  an  APDE.  Defined  as  a  cross-firnctional  integrated  digital  environment  linking  the 
entire  acquisition  program  team,  the  APDE  is  a  realizable,  program  specific  subset  of  the 
DoD-wide  IDE  vision.  APDE  focuses  on  an  individual  acquisition  program  with  its  devel¬ 
opment  controlled  by  the  PM.  APDE  supports  program-specific  requirements  and  enables 
process  improvements,  increases  in  efficiency,  and  reengineering  efforts,  which  are  achiev¬ 
able  by  both  the  PM  office  and  government-industry  acquisition  partners. 

An  APDE  can  range  from  being  very  simple  to  very  conq)lex.  At  the  low  end,  key  people 
may  share  e-mail  and  limited  information  sets  within  the  PMO  and/or  with  the  prime  con¬ 
tractor,  perhaps  incorporating  commercial  software  to  facilitate  data  access.  At  the  high 
end,  an  extensive  digital  infirastructure  enables  every  active  participant  to  have  direct  ac¬ 
cess  to  all  pertinent  data  relating  to  one’s  function  or  process,  regardless  of  the  physical 
location  of  the  database.  These  active  participants  include  not  only  the  PM  office  and 
prime  contraetor  personnel  but  also  sub-contractors,  vendors,  suppliers,  support  agencies, 
and  end  users.  The  elements  may  include  topics  noted  in  section  18.2.3  of  this  chapter. 
What  is  right  for  a  particular  PMO  is  a  point  somewhere  along  a  continuum  of  increasing 
APDE  complexity.  As  with  the  IDE,  the  use  of  standards  to  support  data  exchange  and 
interoperability  are  essential  to  an  APDE. 

18.2.5  Digital  Environment  Summary 

Moving  into  the  information  age  and  exploiting  the  potential  of  integrated  digital  environ¬ 
ments  is  key  to  the  future  success  of  the  acquisition  community.  As  this  movement  neces¬ 
sitates  crossing  functional,  organizational,  and  process  boundaries,  there  are  far  reaching 
imphcations  that  impact  DoD,  the  U.S.  Government,  industry,  and  even  the  international 
community.  The  defense  acquisition  community  must  at  least  be  aware  of  these  factors 
and  attempt  to  take  advantage  of  opportunities  that  they  present.  There  are  many  organi¬ 
zations  that  play  an  active  role  in  information  technology  and  the  digital  environment, 
along  with  numerous  ongoing  and  overlapping  initiatives.  In  some  cases,  ongoing  efforts 
are  beyond  the  control  of  the  PM.  However,  there  is  stUl  much  that  can  be  done  that  will 
enable  the  PMO,  and  industry  partners  to  capitalize  on  such  items  as  the  APDE  initiative. 
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18.3  WHY  USE  A  DIGITAL  PROCESS? 


There  are  two  distinct,  and  somewhat  overlapping,  reasons  for  the  PM  to  transition  from  a 
paper-intensive  environment  to  a  digital  environment.  The  first  is  that  DoD  policy  re¬ 
quires  movement  away  from  paper-based  processes  as  quickly  as  possible.  DoD  Regula¬ 
tion  5000.2-R  requires  all  new  contracts  (starting  in  FY97)  to  require  online  access  to,  or 
delivery  of,  their  programmatic  and  technical  data  in  digital  form.  A  more  compelling  rea¬ 
son  is  that  it  sinply  makes  good  business  sense.  The  importance  of  information  technol¬ 
ogy  to  the  logistics  manager  is  addressed  in  section  18.6  of  this  chapter. 

18.3.1  IPPDs  and  Reengineering 

A  key  element  in  DoD’s  attenpt  to  reengineer  the  acquisition  process  is  the  use  of  Inte¬ 
grated  Product  Teams  (IPTs)  and  IPPD  concepts.  This  is  an  area  where  defense  acquisi¬ 
tion  programs  can  learn  from  industry.  Many  of  the  recent  “success  stories”  in  the  media 
concerning  improvement  in  competitiveness  of  American  firms  can  be  traced  to  the  ag¬ 
gressive  use  of  digital  environments  and  the  creation  of  an  IPPD  environment.  One  ex¬ 
ample  is  Boeing’s  decision  to  use  Computer-Aided  Three-dimensional  Interactive  Appli¬ 
cations  —  CATIA  software  —  for  the  development  of  the  111  aircraft.  Boeing’s  man¬ 
agement  made  the  decision  to  change  the  culture  of  the  company  (IPPD)  and  invest  $100 
million  in  a  computer-aided  development  capability.  The  bigger  “investment”  was  in  the 
total  corporate  commitment  to  this  approach  —  there  was  no  fallback  approach  in  place. 

As  a  result,  there  is  no  physical  mock-up  for  an  aircraft  with  85,000  components  and  over 
four  million  parts.  The  goal  is  to  achieve  the  same  number  of  manufacturing  hours  as  the 
767  -  for  an  aircraft  with  57  percent  greater  empty  weight  -  by  reducing  the  number  of 
design  changes  to  at  least  one-half  of  that  experienced  on  the  767.  To  date,  Boeing  is  re¬ 
porting  a  93  percent  reduction  in  the  number  of  design  changes.  (To  bring  some  balance 
to  the  above  positive  examples,  the  Journal  of  the  DoD  ReUability  Analysis  Center,  Sec¬ 
ond  Quarter  1997,  reports  a  higher  than  expected  rate  of  malfunctions  on  the  111  by  one 
airline  user;  plus  there  are  problems  caused  by  electronic  complexity  and  electromagnetic 
compatibility.) 

A  second  example  illustrates  the  point  that  computer-assisted  integrated  product  devel¬ 
opment  is  not  just  for  large  corporations.  Kohler’s  Engine  Division,  a  producer  of  small  5 
to  25  horsepower  4-cycle  lawn  mower  engines,  is  a  small  player  in  a  big  field.  Their  busi¬ 
ness  strategy  is  fairly  straightforward  —  sell  engines  by  offering  superior  performance  and 
high  reliability  at  a  lower  cost.  Kohler  has  been  using  state-of-the-art  CAD/CAM  [com¬ 
puter-aided  design/computer-aided  manufacturing]  tools  to  introduce  new  designs  that  are 
radically  different  from  earlier  versions,  which  is  quite  a  departure  from  the  evolutionary 
change  approach  traditionally  practiced  by  this  industry.  At  Kohler,  manufacturing  cycle 
times  have  been  cut  significantly.  Physical  prototypes  are  no  longer  necessary.  Kohler  of¬ 
fers  a  2-year  warranty  —  the  longest  in  the  industry. 
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In  these  examples,  both  companies  implemented  the  commercial  equivalent  of  an  APDE  to 
exploit  an  IPPD  environment.  This  was  made  possible  through  the  use  of  an  APDE.  The 
traditional  use  of  prototypes  to  ensure  form,  fit,  and  producibUity  was  obviated  by  the 
APDE’s  ability  to  enable  a  truly  concurrent  engineering  and  development  process.  This 
radical  improvement  in  program  performance  is  a  clear  example  of  why  PMs  should  em¬ 
brace  the  APDE. 

18.3.2  The  APDE  and  DoD 

In  DoD  acquisition  programs,  well  over  half  of  the  total  life-cycle  costs  of  weapon  sys¬ 
tems  are  fixed  early  in  the  program’s  development.  The  PM  should  focus  on  reducing  to¬ 
tal  life-cycle  costs  early  in  the  development  process.  The  APDE  directly  enables  this  to 
occur  by  allowing  the  PM  to  create  an  IPPD  environment  to  ensure  that  all  stakeholders 
are  involved  and  data  and  process  requirements  are  identified  up  front.  The  PM  can  then 
plan  for  reducing  long-term  costs. 

18.4  THE  DOD  DIGITAL  WORLD  IN  1997 

Despite  many  positive  efforts  within  DoD,  the  research  report.  Navigating  the  Digital  En¬ 
vironment:  A  Program  Manager’s  Perspective,  concluded  that: 

‘There  is  no  universal  APDE  standard  or  truth  among  the  organizations 
examined.  There  are  just  too  many  implementation  options  available.  As 
one  expert  in  industry  so  fittingly  stated,  ‘there  is  no  silver  bullet  single  so¬ 
lution.  ...  it  requires  a  major  investment  which  is  difficult  to  find  when  the 
attention  is  on  reducing  overhead  costs  in  a  downsizing  environment.’  Be¬ 
cause  an  APDE-like  concept  is  relatively  new  and  evolving,  an  under¬ 
standing  of  the  context  of  why  and  how  organizations  create  them  is  es¬ 
sential.  Our  research  further  investigated  barriers  encountered  in  adopting 
an  APDE.  Not  surprisingly,  the  researchers  noticed  a  wide-range  of  rea¬ 
sons,  both  supporting  and  limiting  APDE  development.” 

18.4.1  Obstacles 

Even  though  organizations  are  conducting  business  using  digital  technology,  very  few 
possess  a  coherent  game  plan  that  outlines  the  requirements  and  objectives  for  integrating 
digital  environments.  The  knowledge  level  of  particular  software  packages,  like  e-mail, 
word  processing,  and  spreadsheets,  and  their  respective  benefits  to  individuals  is  high. 
Conversely,  the  level  of  understanding  regarding  how  to  integrate  digital  environments 
across  functional  areas  and  processes  is  low. 

Cromar,  Wiley,  and  Tremaine  concluded  that  there  are  many  misconceptions  regarding  the 
need  for  and  general  employment  of  an  integrated  digital  environment.  Only  a  limited 
number  of  the  sites  they  visited  seemed  to  appreciate  what  integrated  digital  environments 
offer,  what  constitutes  an  IDE,  and  what  initiatives  are  available  to  help  their  organization 


18-11 


develop  an  IDE  best  suited  to  meet  their  needs.  Most  organizations  that  did  recognize  the 
need  for  an  IDE  were  not  aware  of  any  resources  available  to  help  them  construct  one. 
Organizations  feel  they  are  on  their  own  and  tend  to  reinvent  the  wheel. 

Other  obstacles  include  the  slow  migration  of  certain  enabling  digital  technologies  within 
DoD,  difficulty  in  selling  the  usefulness  of  information  technology,  decision  makers  be¬ 
lieving  in  information  technology  cost  savings,  and  related  cultural  barriers.  Security  con¬ 
cerns  also  exist  in  the  area  of  proprietary  data  and  classified  data. 

18.4.2  Standards  and  a  Common  Data  Environment 

The  DoD  is  actively  pursuing  the  use  of  commercial  standards  such  as  ANSI  XI 2,  stan¬ 
dard  generalized  markup  language  (SGML),  initial  graphics  exchange  specification 
(IGES),  and  commercial  products  instead  of  government  off-the-shelf  (GOTS)  packages. 
Quite  a  few  organizations  interviewed  by  the  study  group  have  installed  commercial  prod¬ 
ucts  as  a  solution  for  the  management,  exchange,  manipulation,  and  storage  of  electronic 
data.  This  solution  was  used  because  some  DoD-sponsored  standard  systems,  like 
JCALS,  JEDMICS,  and  CMIS,  are  still  not  sufficiently  mature  (in  the  opinion  of  some) 
and  are  considered  to  be  less  capable  than  commercial  alternatives.  According  to  a  senior 
DoD  official,  some  organizations  also  want  to  avoid  the  Ada  (Department  of  Defense  high 
order  software  language)  paradox,  according  to  a  senior  DoD  official,  where  what  had 
been  originally  designed  to  be  a  solution  to  interoperability  has  become  a  burden. 

An  example  of  the  application  of  standards  and  a  common  digital  environment  is  the  Joint 
Strike  Fighter  (JSF)  Program  Office,  formerly  Joint  Advanced  Strike  Technology  (JAST) 
Program  Office.  With  few  exceptions,  this  office  operates  in  a  paperless  environment. 
Early  on,  the  JSF  Program  Office  strangely  pushed  electronic  procurement,  even  though 
there  were  few  standards  or  experienced  personnel  to  guide  such  efforts.  They  train, 
make  decisions,  plan  upcoming  phases,  receive  and  evaluate  deliverables,  award  contracts, 
conduct  frequent  management  reviews,  and  review  technical  information  -  aU  electroni¬ 
cally  in  a  common  data  environment.  In  addition,  they  have  online  access  to  eontractors’ 
management  information  systems  (MIS).  The  JSF  Program  also  uses  an  Internet  web  site 
to  distribute  solicitations,  broad  agency  announcements,  and  Request  for  Proposals 
(RFPs);  respond  to  questions  from  potential  offerors;  inform  prospective  bidders  of  the 
latest  information  that  might  affect  contract  proposals;  and  answer  questions  related  to 
their  solicitations.  The  JSF  Program  has  declared  that  business  with  them  will  take  place 
digitally,  and  it  subscribes  to  a  common  information  systems  environment. 

18.4.3  Near-term  Action 

The  CITIS  is  addressed  in  section  18.2.3.7  of  this  chapter.  The  careful  design  of  a  CITIS 
is  probably  the  most  important  decision  a  PM  can  make  in  satisfying  program  data  needs 
through  an  APDE.  This  is  especially  true  in  light  of  the  requirements  of  DoD  5000.2-R, 
which  states:  “Support  concepts  of  new  and  modified  systems  shall  maximize  the  use  of 
contractor  provided,  long-term,  total  life-cycle  logistics  support.”  In  most  cases,  a 
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contractor’s  CITIS  is  robust  enough  to  provide  easy  access  to  the  data.  Cromar,  Wiley, 
and  Tremaine  revealed  many  variations  in  how  DoD  organizations  estabhsh  and  maintain 
connectivity  among  information  environments.  MIL-STD-974  defines  the  functional  re¬ 
quirements  for  CITIS  and  permits  a  great  deal  of  flexibility  as  evidenced  by  its  four  im¬ 
plementation  strategies: 

•  Database  repository  resides  with  the  prime  contractor  as  a  single  physical  inte¬ 
grated  database. 

•  Database  repository  resides  with  the  prime  contractor  as  distributed  multiple 
databases  with  a  navigator  (gateway  processor). 

•  Database  repository  resides  with  the  prime  contractor;  existing  information  sys¬ 
tems  are  interfaced  to  extract  CITIS  data  in  a  central  repository. 

•  Database  repository  resides  with  the  prime  contractor  and  suppliers  (many), 
with  a  navigator  to  pass  requests/access  to  supplier  databases. 

Some  PMOs  tap  directly  into  a  prime  contractor’s  CITIS,  located  either  inside  or  outside 
the  contractor’s  boundary,  and  extract  the  appropriate  data  on  demand.  Other  PMOs 
avoid  a  CITIS  and  have  the  contractor  dehver  digital  data  to  a  remote  server  that  is  oper¬ 
ated  and  maintained  by  the  sponsor. 

However,  producing  an  efficient  CITIS  and  justifying  its  usefulness  is  not  an  easy  under¬ 
taking.  A  CITIS  should  have  certain  characteristics  that  everyone  on  the  team  under¬ 
stands,  and  it  should  be  simple  to  use.  CITISs  must  be  reliable  and  straightforward;  oth¬ 
erwise,  the  exchange  of  digital  information,  whether  technical  data,  drawings,  schedules, 
or  general  reports,  can  become  a  cumbersome  and  inefficient  operation. 

18.4.4  Digital  World  Summary 

While  there  are  many  ongoing  innovative  digital  initiatives  throughout  DoD,  the  acquisi¬ 
tion  community  is  not  fully  prepared  to  capitalize  on  the  benefits  or  potential  of  integrated 
digital  environments.  Inplementation  of  digital  environments  widely  differs  between  the 
Services  and  PMOs.  Lessons  learned  by  industry  in  the  exploitation  of  the  information 
age  and  information  technology  are  not  weU  understood  or  appreciated  within  PMOs. 

The  driving  forces  for  organizations  to  adopt  APDEs  are  reducing  overall  costs  and  in¬ 
creasing  performance,  not  policy,  mandates,  or  DoD  direction. 

18.5  PROGRAM  MANAGER’S  DIGITAL  CONCERNS 

The  PM  must  have  the  vision  or  ability  to  understand  the  potential  for  a  cross-functional, 
integrated  digital  environment.  Interviews  have  shown  that  extensive  technical  knowledge 
or  detailed,  functional  acquisition  experience  is  clearly  not  a  prerequisite  for  the  success  of 
an  APDE.  In  fact,  too  much  technical  background  or  experience  may  result  in  decisions 


18-13 


being  clouded  by  preconceived  ideas.  The  PM  must  understand  that  information  itself  is 
an  asset  that  needs  to  be  managed  carefully  over  the  entire  life  cycle  of  the  program.  In¬ 
formation  is  more  than  simply  a  gathering  of  data  used  to  describe  assets  and  actions.  In¬ 
formation  has  value,  it  has  multiple  uses  and  purposes,  and  it  supports  everything  relating 
to  the  acquisition  program.  Properly  managed,  information  can  save  time,  increase  effi¬ 
ciency,  improve  system  quality  and  performance,  and  reduce  cost.  The  APDE  enables  this 
effective  management  of  information  and  information  processes. 

18.5.1  Gain  Access  to  the  Right  Tools 

In  most  PMOs,  there  exists  a  general  lack  of  experience  and  knowledge  with  respect  to 
the  potential,  requirements,  capabilities,  and  limitations  of  an  integrated  digital  environ¬ 
ment.  DoD  acquisition  personnel,  and  many  industry  managers  for  that  matter,  do  not  feel 
adequately  prepared  to  develop  an  APDE  infrastructure.  The  general  sentiment  from  sev¬ 
eral  study  interviewees  was  that,  “we  don’t  even  know  enough  to  ask  the  right  questions, 
let  alone  come  up  with  the  answers.”  It  is  important  for  the  PMO  to  be  able  to  access  in¬ 
formation  and  personnel  that  can  help  them  negotiate  an  APDE  development  effort.  The 
PM  needs  individuals  with  an  understanding  of  APDE-related  areas  such  as  available  tech¬ 
nology;  network  support  and  network  security;  communications  requirements  and  capa¬ 
bilities;  data  rights  and  access  restrictions;  CITIS;  computer-aided  design/computer-aided 
manufacturing  (CAD/CAM);  CALS;  EC/EDI;  national  and  international  standards;  and 
lessons  learned  from  other  PMO  initiatives.  In  many  cases  the  information  and  assets  are 
not  found  within  the  PMO.  Training  programs,  other  DoD  agencies,  and  PMOs,  consult¬ 
ants,  outside  research,  and  contractors  should  be  used  extensively  to  support  the  APDE 
development  process. 

18.5.2  Policy  Matters 

18.5.2.1  Programmatic  Data.  DoD  5000.2-R  states  that,  beginning  in  FY97,  all  new 
contracts  shall  require  online  access  to,  or  delivery  of,  their  programmatic  and  technical 
data  in  digital  form,  unless  analysis  shows  that  life-cycle  time  or  life-cycle  costs  would 
be  increased  by  doing  so.  Preference  shall  be  given  to  online  access  to  contractor- 
developed  data  through  contractor  information  services  rather  than  data  delivery.  No  on¬ 
going  contract,  including  negotiated  or  priced  options,  shall  be  renegotiated  solely  to  re¬ 
quire  the  use  of  digital  data,  unless  analysis  shows  that  life-cycle  costs  would  be  reduced. 
This  final  item  is  being  considered  for  revision. 

18.5.2.2  MAISs.  Further,  DoD  5000.2-R  describes  operating  procedures  that  are  man¬ 
datory  only  for  Major  Defense  Acquisition  Programs  (MDAPs),  Major  Automated  Infor¬ 
mation  System  (MAIS)  acquisition  programs,  and  for  other  acquisition  programs  as  spe¬ 
cifically  stated  therein.  DoDD  8000. 1  provides  complementary  guidance  for  MAIS  func¬ 
tional  areas  and  describes  management  principles  that  are  mandatory  for  all  information 
management  activities,  including  those  related  to  acquisition  of  information  systems, 
resources,  services,  and  infrastructures. 
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An  AIS  acquisition  program  is  a  program  that  (1)  is  designated  by  the  Assistant  Secretary 
of  Defense  (Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance 
and  Reconnaissance)  as  a  MAIS  or  (2)  is  estimated  to  require  program  costs  in  any  single 
year  in  excess  of  $30  million  in  fiscal  year  FY96  constant  dollars,  total  program  costs  in 
excess  of  $120  million  in  FY96  constant  dollars,  or  total  life-cycle  costs  in  excess  of  $360 
million  in  FY96  constant  dollars.  MAIS  acquisition  programs  do  not  include  highly  sensi¬ 
tive  classified  programs  (as  determined  by  the  Secretary  of  Defense).  For  the  purpose  of 
determining  whether  an  AIS  is  a  MAIS,  the  following  shall  be  aggregated  and  considered 
a  single  AIS: 

(1)  the  separate  AISs  that  constitute  a  multi-element  program; 

(2)  the  separate  AISs  that  make  up  an  evolutionary  or  incrementally  developed 
program;  or 

(3)  the  separate  AISs  that  make  up  a  multi-component  AIS  program. 

18.5.2.3  Technology  Life  Cycle.  Numerous  DoD  senior  leaders  have  made  official  refer¬ 
ence  to  information  technology  (IT)  having  a  life  cycle  of  15  to  18  months  or  less.  The 
literature  (government  and  commercial)  is  full  of  articles  on  new  engineering  developments. 
Subjects  include  a  new  computer  fi*om  Sandia  National  Laboratories  with  broad  military 
and  commercial  applications.  It  operates  at  nearly  2  trillion  floating  operations  per  second 
to  nano-technology  or  molecular  manufacturing  allowing  most  products  to  be  made 
lighter,  stronger,  smarter,  cheaper  and  more  precisely  by  rearranging  atoms  and  molecules. 
However,  as  noted  by  Dr.  D.  L.  Losman  and  Dr.  K.  B.  Moss  of  the  Industrial  College  of 
the  Armed  Forces  in  the  May  1996,  Defense  &  Security  Electronics: 

“...  demands  of  the  commercial  market  have  forced  producers  to  change  sys¬ 
tems  often  to  remain  competitive.  It  is  hard  to  imagine  that  the  U.S.  defense 
sector,  given  Congressional  and  presidential  budgetary  and  oversight  demands, 
would  be  able  to  accommodate  the  frequency  of  change  that  is  the  rule  in  the 
free-market  commercial  sector.  Even  if  overall  costs  of  electronics  systems 
drop  and  thus  allow  more  frequent  changes  to  be  financially  possible  (espe¬ 
cially  due  to  declines  in  the  prices  of  hardware).  Congressional  budget  review 
encourages  adoption  of  defense  systems  that  have  longevity.  Importantly,  if 
the  commercial  world  continually  abandons  older  products  as  it  moves  toward 
newer  designs  and  concepts,  how  will  the  military  be  able  to  provide  logistical 
support  and  maintenance  when  the  commercial  products  originally  utihzed  are 
no  longer  being  produced?” 

For  the  DoD,  this  becomes  a  problem  as  commercial/non-developmental  (C/NDI) 
purchases  become  the  rule  for  IT ;  but,  for  both  DoD  and  commercial  markets,  two 
other  problems  arise.  First,  when  do  you  execute  a  purchase  of  a  new  or  replacement 
IT  knowing  significant  hardware/software  improvements  are  likely  to  occur  in  the 
near  term,  i.e.,  how  do  you  calculate  your  return  on  investment?  For  DoD,  the  rela¬ 
tive  slowness  of  the  procurement  process  can  mean  that  technology  in  the  newly  ac¬ 
quired  product  may  be  overtaken  before  the  purchase  is  executed.  Second,  in  a 
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logistics  context,  support  plans  for  a  new  system  may  be  delayed  to  the  detriment  of 
the  new  system  because  of  delayed  IT  decisions.  These  decisions  are  delayed  because 
of  the  desire  to  use  the  latest  IT  in  the  system  or  in  support  of  the  system.  Thus,  an 
insidious  IT  system/support  decision  loop  can  develop.  Conversely,  using  currently 
available  IT  almost  guarantees  near  immediate  obsolescence.  Discussion  of  these  is¬ 
sues  are  conspicuously  absent  in  the  literature. 

18.5.3  The  PM  Must  Be  Involved 

The  DoD  strategy  for  an  integrated  data  environment  (IDE)  is  being  developed  by  the 
DoD  CALS  office.  Although  CALS  officially  encompasses  the  entire  life  cycle  of  a  pro¬ 
gram,  the  effort  is  run  by  the  logistics  community  and  has  historically  had  a  logistics  focus. 
As  a  result,  there  is  a  tendency  by  materiel  acquisition  and  program  management  to  rele¬ 
gate  IDE  and  CALS  issues  to  their  senior  logistics  personnel.  This  is  a  mistake.  The  PM 
must  understand  that  the  APDE,  an  acquisition  program’s  functional  equivalent  to  the 
IDE,  potentially  interconnects  all  program  processes  to  become  an  indispensable  tool  for 
the  PM. 

18.6  LOGISTICS  BENEFITS  OF  INFORMATION  TECHNOLOGY 
18.6.1  Joint  Logistics 

Information  technology  offers  significant  capabihties  to  Commanders-in-Chiefs  (CINCs) 
as  outlined  in  the  Joint  Staffs  second  draft  of  Focused  Logistics,  30  April  1997.  This 
draft  states  that  “information  fiision”  is  a  primary  tenant  of  Focused  Logistics  and  is  de¬ 
fined  as  “...  the  timely  and  accurate  access  and  integration  of  logistics  data  across  units 
and  combat  support  agencies  throughout  the  world  providing  reliable  asset  visibility  and 
access  to  logistics  resources  in  support  of  the  warfighter.”  Accordingly,  Global  Combat 
Support  Systems  (GCSS)  is  a  strategy  to  provide  universal  access  to  information  and 
interoperability  of  that  information  across  combat  support  and  ultimately  between  combat 
support  and  command  and  control.  A  host  of  logistics  information  technology  systems 
enablers  are  critical  to  GCSS.  These  initiatives  are: 

•  automatic  identification  technology  —  ensures  capturing  source  data  from  exist¬ 
ing  and  future  automated  information  systems  such  as  bar  codes,  optical  memory 
cards,  radio  fi'equency  tags  and  movement  tracking; 

•  joint  total  asset  visibility  —  provides  users  with  information  on  the  location, 
movement,  status,  and  identity  of  units,  personnel  and  supplies; 

•  intransit  visibility  —  tracks  the  identity,  status,  and  location  of  DoD  unit  and  non¬ 
unit  cargo,  passengers,  and  medical  patients  from  origin  to  any  destination;  and 

•  joint  decision  support  tools  —  aggregates,  categorizes,  and  depicts  information 
on  force  composition,  environment,  intensity  and  expected  duration  of  operations. 
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18.6.2  Service  Logistics 


18.6.2. 1  General  Benefits.  A  primary  objective  of  DoD  information  technology  activity  is 
to  dramatically  reduce  product  cycle  times,  to  reduce  DoD  acquisition  and  support  costs, 
and  to  inprove  readiness  through  reengineering  acquisition  and  logistics  processes.  To 
attain  these  objects,  the  CALS’  initiative  provides  the  reengineering  methodology,  inte¬ 
grated  information  systems,  and  information  standards  that  are  necessary  to  re-invent  ac¬ 
quisition  and  logistics  processes  across  the  Department.  Furthermore,  CALS’  reliance  on 
global  standards  versus  defense-unique  requirements  directly  facilitates  commer¬ 
cial/military  integration  and  defense  conversion  through  streamlined  processes  that  reflect 
world-class  operations.  As  such,  the  CALS  initiative  directly  supports  ongoing  DoD  Ac¬ 
quisition  Reform  and  logistics  modernization  efforts  to  reduce  cycle  time  and  life-cycle 
costs.  Specific  examples  include: 

•  improving  weapon  system  schedule  and  cost  performance  through  reengineering 

and  implementation  of  IDE; 

•  reducing  the  regulatory  cost  premium  through  policy  reformation;  and 

•  enhancing  readiness  through  infrastructure  modernization. 

18.6.2.2  Specific  Benefits.  At  this  writing,  the  PM  of  Combat  Mobility  Systems  (CMS)  is 
a  fuUy  chartered  element  of  the  Program  Executive  Office,  Armored  Systems  Moderniza¬ 
tion,  responsible  for  the  development  and  fielding  of  three  weapon  systems: 

•  Ml  Breacher  (Grizzly) 

•  Heavy  Assault  Bridge  (Wolverine) 

•  Improved  Recovery  Vehicle  (Hercules) 

The  first  two  systems  are  derivatives  of  the  Ml  Abrams  and  support  engineer  mission  on 
the  battlefield;  the  third  system  is  a  major  improvement  to  the  M88  Recovery  Vehicle  and 
supports  ordnance  missions.  United  Defense,  Limited  Partnership  (UDLP),  York,  PA, 
serves  as  the  prime  contractor  for  Grizzly  and  Hercules,  while  General  Dynamics  Land 
Systems  (GDLS),  Sterling  Heights,  MI,  is  the  prime  contractor  for  the  Wolverine. 

The  PM,  CMS  information  technology  concepts,  planning,  implementation,  and  approxi¬ 
mately  25  of  the  program’s  logistics-oriented  benefits  fi*om  this  initiative  are  documented 
in  a  five-page  narrative  on  the  “Web.”  The  reader  is  urged  to  review  this  material  at: 

http://www.acq.osd.mil/cals/implcals.html 
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Broader  examples  of  the  logistics  benefits  of  Service  application  of  information  technology 
are: 


•  Multi-user  ECP  Review  System  (MEARS).  MICOM  is  automating  the  Engineer¬ 
ing  Change  Proposal  (ECP)  review  process  with  the  development  of  MEARS. 
MEARS  provides  a  tool  to  electronically  review,  comment,  and  vote  on  ECPs 
submitted  by  contractors.  In  the  first  year  using  MEARS,  the  Patriot  Missile  Proj¬ 
ect  Office  saved  $250  thousand  in  paper  alone. 

•  Automated  Logistics  Publishing  System  (ALPS).  ALPS,  a  computer-generated 
publishing  tool,  is  providing  significant  savings  in  the  time  and  resources  needed  to 
support  logistics  pubhcations.  In  addition  to  improved  document  quality,  produc¬ 
tion  cycle  time  has  gone  from  6  months  to  a  few  days;  and  the  production  cost  per 
page  has  been  reduced  by  72  percent,  saving  more  than  $5.2  million  over  an  18- 
month  period. 

•  Navy  Interactive  Electronic  Technical  Manuals  (lETMs).  The  Navy  has  experi¬ 
enced  financial  savings  on  several  systems  employing  lETMs  relative  to  traditional 
documentation  methods.  In  an  effort  to  further  reduce  the  cost  of  lETMs  them¬ 
selves,  the  Navy  conducted  a  project  to  advance  the  technology  necessary  to  allow 
for  the  automated  conversion  of  legacy  technical  manuals  (text,  tables  and  graph¬ 
ics)  to  the  lETM  revisable  database  format  (structured  in  accordance  with  MIL-D- 
87269).  The  conversion  was  to  be  accoirqjlished  with  little  or  no  human  interven¬ 
tion.  That  goal  was  achieved  in  December  1996.  As  a  result  of  the  development 
of  this  automated  conversion  system,  the  cost  of  converting  legacy  technical 
manuals  can  be  reduced  firom  the  current  $130+  per  page  to  a  range  of  $40  per 
page  or  less.  By  transferring  the  technology  to  the  commercial  sector  for  devel¬ 
opment  of  commercial  items,  the  Navy  and  DoD  are  relieved  of  the  financial  bur¬ 
den  of  maintaining,  enhancing,  and  supporting  a  software  system  over  a  long  pe¬ 
riod  of  time. 

•  Advanced  Technical  Information  Support  (ATIS).  ATIS  integrates  digital  engi¬ 
neering  drawings,  technical  manuals,  maintenance,  and  operational  data  through 
shipboard  processing  systems.  Elimination  of  aperture  cards  reduced  reproduction 
costs  per  ship  from  $54  thousand  to  $10.5  thousand  per  year  and  reduced  the  eight 
of  shipboard  storage  media  by  close  to  two  tons.  Also,  search  and  retrieval  re¬ 
sources  dropped  from  four  experts  to  one  novice  per  request;  and  the  time  needed 
to  conduct  a  search  has  decreased  from  30  hours  to  10  minutes. 

•  ATIS  for  Naval  Air  Weapons  System  (ATIS/AIR).  ATIS/ AIR  provides  weapon 
system  digital  technical  data  at  central  technical  publications  hbraries  (CTPLs), 
staff  offices,  and  maintenance  workstations.  It  improves  supply  and  maintenance 
process  times;  reduces  the  size,  weight,  and  volume  of  shipboard  CTPLs  an  aver¬ 
age  of  90  percent;  and  reduces  hbrarian  workloads  by  30  percent  for  posting  and 
distribution  of  technical  data  revisions. 
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PART  IV 


SPECIAL  TOPICS 


19 

CONTRACTOR  LOGISTICS  SUPPORT 
AND  WARRANTIES 


You  can’t  fly  an  aircraft  without  two  tails, 
one  of  which  stretches  back  to  the  prime. 

Hangar  philosophy 


19.1  DEFINITIONS 

•  Contractor  logistics  Support  (CLSl  is  the  performance  of  maintenance  and/or 
material  management  functions  for  a  DoD  system  by  a  commercial  activity.  It  is 
DoD  policy  to  maximize  the  use  of  long-term  CLS  in  support  concepts  for  new 
or  modified  systems.  In  addition  to  the  three  levels  of  maintenance 
(organizational,  intermediate,  and  depot),  support  may  include  provisioning, 
management,  distribution,  or  repair  of  system  spares.  Planning  for  CLS  should 
be  documented  in  the  support  plan  for  the  item  being  acquired.  Further,  CLS 
can  effectively  be  utilized  to  support  depot  field  teams,  low-surge  workloads, 
small  workloads,  commercial  off-the-shelf  items,  and  short  life  cycle  or  rapidly 
obsolete  items.  Additionally,  CLS  should  be  considered  for  high-surge 
workloads  that  either  involve  unique  processes  for  capabilities  that  cannot  be 
established  organically  at  reasonable  cost  or  for  any  support  factors  that  clearly 
demonstrate  a  potential  for  lower  costs  and/or  increased  readiness. 

•  Product  Assurance  Plan  implements  a  product  assurance  program  including 
Reliability,  Availability,  and  Maintainability  (RAM),  quality  hardware  and 
software,  and  system  assessment  to  ensure  user  satisfaction,  mission  and 
operational  effectiveness,  and  performance  to  specified  requirements. 

•  Warranty  is  a  promise  or  affirmation  given  by  a  contractor  to  the  government 
regarding  the  nature,  usefulness,  or  condition  of  the  supplies  or  performance  of 
services  furnished  under  a  contract.  Refer  to  Title  10  U.S.C.  §2403  for  the 
mandatory  use  of  warranties  in  systems  acquisition. 

19.2  CONTRACTOR  LOGISTICS  SUPPORT  (CLS) 

19.2.1  The  Benefits 

The  benefits  of  proper  implementation  of  CLS  foUow. 
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•  a  reduction  in  the  annual  appropriated  spares  requirements,  assuming  that  the 
CLS  contract  results  in  a  reduction  in  pipeline  spares; 

•  a  reduction  in  the  DoD  infrastructure  (e.g.,  manpower,  spares,  facilities,  etc.)  as 
the  contractor  assumes  management  and  maintenance  responsibilities; 

•  a  long-term  increase  in  component  reliability  at  limited  cost  to  the  government, 
assuming  the  CLS  contract  incentives  provide  an  appropriate  profit  motive  for 
realized  reliability  growth;  and 

•  assistance  with  the  maintenance  of  the  defense  industrial  base  in  times  of  tight 
defense  budgets. 

19.2.2  The  Challenges 

The  implementation  of  a  CLS  contract  is  not  without  its  challenges  and  constraints.  The 
Logistics  Manager  (LM)  should  be  aware  of  these  challenges  and  make  appropriate  efforts 
to  develop  the  support  program  around  them  At  least  two  of  the  challenges  are  derived 
from  legislation  and  regulation: 

•  Legislation  mandates  that  60  percent  of  depot-level  maintenance  will  be 
performed  organically. 

•  The  Federal  Acquisition  Regulations  (FAR)  and  the  budget  processes  restrict 
contract  length.  Currently,  DoD  is  restricted  to  a  contract  length  of  one  year, 
with  four  successive  one-year  options;  the  options  can  be  exercised  at  the 
pleasure  of  the  government.  With  the  service  life  of  many  DoD  systems 
reaching  out  to  30  years  or  more,  this  limitation  adds  an  element  of  risk  and 
uncertainty  to  the  CLS  approach. 

Other  considerations  include  providing  for  wartime  surge  demands,  sufficient  organic 
workload  to  maintain  organic  expertise,  and  appropriate  levels  of  competition  in  contract 
awards.  The  LM  must  also  cope  with  the  effect  of  the  contractor’s  learning  curve  when 
competition  leads  to  a  change  of  contractors. 

19.2.3  Automated  Tools 

There  are  only  a  few  automated  tools  to  assist  in  the  development  or  management  of  a 
CLS  contract,  and  they  are  limited  in  availability  and  function.  Currently  the  most  popular 
tool  in  classroom  use  at  DSMC  is  COMPASS,  which  is  being  revised  as  a  Windows  95 
compatible  program  The  Navy  has  a  software  package  in  use  today,  CAMMS,  which 
displays  status  of  assets  undergoing  repair  at  contractor  facilities.  CAMMS  allows  the 
item  manager  to  maintain  100  percent  visibility  of  commercial  assets,  as  if  they  were  being 
worked  on  at  an  organic  site.  Additionally,  the  Internet  provides  information  regarding 
CLS. 
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19.2.4  Points  of  Contact 


•  ASC/XLXS  (DSN  785-2553) 

•  HQ  AFMC/D  RMP  (DSN  787-7280) 

•  OCALC/LK  (DSN  336-5772) 

•  OOALC/LIR  (DSN  111-mA) 

19.1.6  References 

•  DoD  5000.2-R 

•  U.S .  Air  Force  Instruction  21-102 

•  U.S.  Army  Regulation  700-12,  Chapter  5 

•  DoD  Acquisition  Deskbook 

19.3  WARRANTIES 
19.3.1  Description 

The  principal  purposes  of  a  warranty  in  a  government  contract  are  to  delineate  contractor 
and  government  rights  and  obligations  for  defective  items  and  services,  and  to  foster 
quality  performance.  Generally,  a  warranty  should  provide  the  following: 

•  a  contractual  right  for  the  correction  of  defects  notwithstanding  any  other 
requirement  of  the  contract  pertaining  to  acceptance  of  the  supplies  or  services 
by  the  government;  and 

•  a  stated  period  of  time  or  use  or  the  occurrence  of  a  specified  event  after 
government  acceptance  when  a  contractual  right  for  the  correction  of  defects 
can  be  asserted. 

The  benefits  to  be  derived  firom  a  warranty  must  be  commensurate  with  the  cost  of  the 
warranty  to  the  government.  In  1985,  Congress  established  a  requirement  for  express 
warranties  in  production  contracts  for  systems  that  exceed  a  unit  cost  of  $100,000  or  $10 
million  total  cost.  The  warranties  address  conformity  to  the  design  and  manufacturing 
requirements,  freedom  from  defects  in  materials  and  workmanship  at  the  time  of  delivery, 
and  conformity  to  “essential  performance  requirements”  (such  as  operation  capabilities 
and  reliability).  In  effect,  the  warranty  is  an  obligation  on  the  part  of  the  contractor  to 
repair  or  replace  equipment  found  defective  or  to  compensate  the  government  for  repair 
performed  by  the  government  during  the  course  of  the  warranty  period. 
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The  FAR  and  the  Defense  Federal  Acquisition  Regulations  Supplement  (DFARS)  also 
provide  policies  and  procedures  for  tailoring  the  required  warranties  to  the  circumstances 
of  a  particular  procurement  and  for  obtaining  waivers  when  needed.  For  supplies  and 
services  that  do  not  meet  the  definition  of  a  system,  such  as  spares  and  data,  warranties 
may  be  used,  if  they  meet  or  exceed  the  foregoing  thresholds  and  are  advantageous  to  the 
government.  A  warranty  of  technical  data  (extended  liability)  should  normally  be  included 
in  the  solicitation  and  evaluated  on  its  merits  during  source  selection. 

19.3.2  Guidelines 

Warranties  can  offer  unique  opportunities  to  implement  innovative  cost  and  supportabHity 
solutions.  Use  of  warranties  should  be  included  in  risk  management  studies.  Applications 
for  logistics-oriented  warranty  considerations  include  these  factors: 

•  Nondevelopmental  Items  (NDIs)  and  Commercial  Items  (CIs), 

•  increasing  reliability  in  fielded  systems, 

•  system  complexity, 

•  projected  system/equipment  usage  rates, 

•  reliability  testing  and  results, 

•  cost  benefit  analyses, 

•  commercial  repair,  and 

•  CLS. 

Warranties  must  be  bilateral  agreements  between  government  and  industry.  For 
warranties  to  be  successful,  they  must  offer  benefits  to  all  parties  involved. 

The  type  of  contract  used  to  acquire  spare  parts  or  repair  services  limits  the  extent  to 
which  warranties  can  be  used  successfully.  Warranties  are  normally  applied  to  the  fixed- 
price  type  of  contracts.  They  are  less  appropriate  for  Fixed  Price  Incentive  fee  (FPIF) 
target  contracts.  The  cost-sharing  mechanism  of  FPIF  contracts  normally  means  that  the 
government  wiU  incur  a  substantial  portion  of  the  costs  associated  with  warranty  repairs 
and  correction  of  deficiencies.  They  should  not  be  used  in  cost-reimbursable  contracts 
since  the  government  would  pay  for  most,  if  not  aU,  of  the  costs  associated  with  the 
warranty.  In  such  cases,  incentive  or  award  fee  provisions  should  be  used  to  provide 
profit  incentives  to  obtain  desired  contractor  performance. 

Appendix  E  of  the  DoD  Flexible  Sustainment  Guide  (see  Section  19.3.3  below)  provides 
helpful  guidance  for  the  selection  of  appropriate  types  of  warranties.  It  suggests  warranty 
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types  that  should  be  considered  dependent  upon  whether  contracting  for  spare  parts  or 
repair  services.  Reliability  Based  Logistics  (RBL)  is  a  subject  discussed  in  Chapter  26, 
Section  26.4,  of  this  Guide.  Certain  criteria  associated  with  RBL  impact  the  type  of 
warranty  that  should  be  used. 

In  designing  or  selecting  the  contract  warranty  clause,  the  LM  should  consider  the 
following  guidelines: 

•  Maximize  the  government’s  ability  to  use  the  warranty.  Be  sure  to  consider 
transportation  and  storage  factors. 

•  Provide  a  mechanism  for  administering  the  warranty  that  imposes  limited  or  no 
special  reporting  requirements  on  the  user  personnel,  particularly  at  the 
organizational  level. 

•  Avoid  warranty  clauses  and  procedures  that  will,  when  exercised,  have  an 
adverse  impact  on  readiness.  (An  example  would  be  excessive  downtime  while 
waiting  for  contractor  replacement  or  repair  of  the  warranted  components.) 

19.3.3  Reference  and  Point  of  Contact 

DoD  Flexible  Sustainment  Guide  of  23  January  1997.  Mr.  Jerry  Beck  of  NAVAIR  is  the 
point  of  contact;  his  telephone  number  is  (301)  342-3838,  ext.  188. 
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20 

SOFTWARE  LOGISTICS 

“Planning  for  supportability  up  front  is  a  major  determinant  of  software  devel¬ 
opment  success.  Software,  not  developed  with  maintenance  in  mind,  can  end  up 
so  poorly  designed  and  documented  that  total  re-development  is  actually 
cheaper  than  maintaining  the  original  code.  ” 

20.1  DoD  5000.2-R  POLICY 

Software  shall  be  managed  and  engineered  using  best  processes  and  practices  that  are  known  to 
reduce  cost,  schedule,  and  technical  risks.  It  is  DoD  policy  to  design  and  develop  software  sys¬ 
tems  based  on  systems  engineering  principles,  including  the  following: 

•  developing  software  system  architectures  that  support  open  system  concepts,  exploit 
commercial  computer  systems  products,  and  provide  for  incremental  improvements 
based  on  modular,  reusable,  extensible  software; 

•  identifying  and  exploiting  software  reuse  opportunities,  government  and  commercial, 
before  beginning  new  software  development; 

•  considering  Ada  programming  language  (no  longer  an  across-the-board  requirement)  to 
develop  code  for  the  life-cycle  maintenance  and  support,  ^  for  which  the  government  is 
responsible. 

•  using  DoD  standard  data;  (Additional  guidance  is  contained  in  DoDD  8320. 1 .) 

•  selecting  contractors  with  the  domain  experience  in  developing  con^arable  software 
systems,  a  successful  past  performance  record,  and  a  demonstrable  mature  software  de¬ 
velopment  capability  and  process;  and 

•  using  software  metrics  to  effect  the  necessary  discipline  of  the  software  development 
process  and  assess  the  maturity  of  the  software  product. 


‘  Guidelines  for  Successful  Acquisition  and  Management  of  Software -Intensive  Systems,  Vol.  1,  Part  2,  Version  2, 

June  1996.  ^  u  ^nc,e. 

^  In  accordance  with  DoD  policies,  based  on  recommendations  from  a  National  Academy  of  Sciences  October  1996 

study,  programming  language  selections  should  be  made  in  the  context  of  the  system  and  software  engineering 

factors  that  influence  overall  life-cycle  costs,  risks,  and  potential  for  interoperability. 
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20.2  DEFINITIONS 


•  Software  is  a  set  of  eoded  eomputer  instruetions  and  assoeiated  procedural  data  that  di¬ 
rect  computer  hardware  to  perform  computations  or  control  functions. 

•  Firmware  is  a  marriage  of  software  and  hardware  in  which  read-only  type  of  software  is 
installed  in  a  hardware  item.  As  a  result,  the  software  element  is  difficult  to  change  or 
update  once  it  is  installed. 

•  Computer  Software  Configuration  Item  (CSCD  or  Software  Item  (SB  is  a  functionally 
or  logically  oriented  set  of  software  that  is  controlled  by  configuration  management  in 
the  same  maimer  as  an  item  of  hardware. 

•  Computer  Software  Documentation  is  the  technical  documentation  that  describes  the 
capabilities  and  limitations  of  a  CSCI  or  SI;  it  also  provides  operation  or  maintenance  in¬ 
structions  for  the  software. 

•  Hardware  Configuration  Item  (HWCI)  is  a  functionally  or  logically  oriented  distinct  set 
of  firmware  that  is  controlled  in  the  same  manner  as  a  CSCI  or  SI. 

20.3  BACKGROUND 

Software  is  present  throughout  a  typical  weapons  system,  in  both  mission-critical  applications 
programs  and  the  related  support  structure.  Figure  20-1  graphically  portrays  the  many  software 
applications  that  might  be  present  in  such  a  system.  Clearly,  today’s  acquisition  personnel  require 
an  understanding  of  hardware,  software,  and  firmware  within  the  context  of  the  acquisition  process. 

The  bulk  of  the  DoD’s  annual  expenditures  for  software  is  for  Postdeployment  Software  Support 
(PDSS).  (See  Figure  20-2.)  Since  the  1960’s,  software  costs  have  risen  at  a  proportionately 
greater  rate  than  other  system  costs.  Over  the  past  several  decades,  the  flexibility  of  software  has 
generated  a  progressive  trend  of  replacing  hardware  with  software  wherever  technologically  fea¬ 
sible.  Figure  20-3  shows  the  growth  in  the  size  of  software  from  the  introduction  of  the  F-4  air¬ 
craft  in  the  1960  timefi-ame  to  the  present.  In  addition  to  size,  complexity  is  on  the  rise;  this  trend 
affects  every  phase  of  the  software  life  cycle  from  design  to  testing  and  support.  The  costs  of 
software  will  continue  to  rise  dramatically.  Program  offices  will  need  to  take  action  to  mitigate 
the  effects  of  increasing  reMance  of  software.  The  program  office  will  need  greater  understanding 
of  the  risks  associated  with  the  software  development  process  and  how  such  risks  can  be  miti¬ 
gated.  They  must  also  develop  a  willingness  to  address  long-term  software  supportability  issues. 

In  fact,  these  trends  indicate  that  the  future  capability  of  our  major  software-intensive  systems  is 
inexorably  dependent  on  the  Services’  ability  to  cost-effectively  maintain  them. 
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SUPPORT  SOFTWARE 

•  COtiPOJERS 

•  DUQNOSTIC  ROUTINES 

•  DEBUGCmO  ROUTINES 

•  UTILITY  PROGRAMS 

•  VALlOATION/VERIFtCATIONAIDS 

•  LOADER 

•  LINKAGE-EDITOR 

•  TASK  DRIVER 

•  TEST  TAPE  GENERATORS 

•  SMUUTIONS 

•  MODULE  TEST  TOOLS 

•  DATA  REDUCTION  AIDS 

•  COI«%URATION  MANAGBiENT  TOOLS 

•  METRtCSTOCM^ 


Figure  20-1:  Types  of  Software 
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Figure  20-2:  Software  Cost/Effort  Distribution 
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WEAPON  SYSTEM 

LINES  OF  CODE 

F-4 

2,000 

F-16D 

236,000 

C-17 

2,000,000 

B1-B 

1,200,000 

F-22 

7,000,000 

Figure  20-3:  Weapon  System  Software  Complexity 


20.4  LOGISTICS  CONSIDERATIONS^ 

Many  of  the  basic  logistics  concepts  apply  to  software  planning.  Design  criteria  for  supportabUity 
should  be  established  for  software  just  as  they  are  for  hardware.  Reliability  and  maintainability 
should  be  addressed  in  detail.  MIL-STD  882B  addresses  the  safety  aspects  of  software  because 
the  hazards  associated  with  software  malfunctions  must  be  thoroughly  examined  and  eliminated 
where  necessary.  Each  of  the  ten  elements  of  logistics  support  should  be  considered  for  the  im¬ 
pact  of  software,  just  as  for  hardware.  A  listing  of  the  logistics  elements,  together  with  the  soft¬ 
ware  issues  associated  with  each,  is  contained  in  Chapter  7  of  this  Guide.  Although  logistics  con¬ 
cepts  for  software  are  sunilar  to  those  for  hardware,  there  are  some  key  differences: 

•  Software  does  not  fail  in  the  classical  sense.  Hardware  typically  degrades  over  time  as 
components  wear  out.  A  software  problem  is  due  to  an  error  that  has  existed  in  the 
program  since  its  creation.  (Refer  to  Figure  20-4.)  When  a  problem  caused  by  a  com¬ 
ponent  failure  is  found  in  hardware,  the  “solution”  entails  bringing  the  hardware  item 
back  to  its  original  configuration  (the  product  baseline).  In  the  case  of  software,  when  a 
problem  is  found  and  corrected,  a  new  configuration  is  created.  Hence  software  “main¬ 
tenance”  inherently  involves  continuous  changes  to  the  product  baseline. 

•  Software  does  not  wear  out  like  hardware,  so  the  term  “software  maintenance,”  al¬ 
though  widely  used  by  commercial  industry,  is  technically  a  misnomer.  The  appropriate 
name  for  this  effort  is  software  support.  It  is  for  this  reason  that  PDSS  is  often  called 
the  redevelopment  phase.  As  defined  by  the  Institute  of  Electrical  and  Electronics  Engi¬ 
neers  (IEEE),  software  maintenance  (i.e.,  support)  is  the  “modification  of  a  software 
product  after  delivery  to  correct  faults,  to  improve  performance,  or  other  attributes,  or 
to  adapt  the  product  to  a  changed  environment.” 


^  Section  20.4  and  its  subsections  contain  information  extracted  from  the  “Aerospace  Infmnation  Report  -  AIR5121”  of 
the  Society  of  Automotive  Engineers’  G-1 1  Reliability,  Maintainability,  Supportability,  and  Logistics  (RMSL) 
Software  Committee,  September  1966.  Information  is  also  extracted  from  the  “Guidelines  for  Successful  Acquisi¬ 
tion  and  Management  of  Software-Intensive  Systems,”  Vol.  1,  Part  2,  Version  2.0  of  June  1996,  available  from  the 
Software  Technology  Support  Center,  Ogden  ALC/TISE,  Hill  AFB,  UT  84056-5205. 
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•  The  computer  programmers  involved  in  software  support  require  programming  skills 
approximating  those  of  the  original  software  developers.  The  programming  effort  en¬ 
tailed  in  introducing  software  changes,  whether  in  the  form  of  corrective  action  or  per¬ 
formance  enhancement,  is  frequently  just  as  challenging  as  that  entailed  in  creating  an 
initial  CSCI.  A  major  difterence  between  the  software  developer  and  the  software 
maintainer  is  that  the  former  has  no  product  knowledge  because  the  product  does  not 
yet  exist;  the  software  maintainer,  on  the  other  hand,  must  have  complete  product 
knowledge  to  do  his  job  weU.  In  this  sense,  software  support  may  be  at  a  slightly  higher 
skill-level  requirement  than  software  development. 

20.4.1  Key  Elements  of  a  Software  Support  Concept 

At  the  simplest  implementation  level,  a  software  support  concept  identifies  a  software  engmeenng 
capability  with  the  personnel  resources  and  skills,  physical  facilities,  and  support  systems  to  un¬ 
dertake  ongoing  development  and  change  implementation.  A  customer/supplier  procedural  in¬ 
terface,  through  which  queries,  change  requests,  and  updated  products  pass,  must  also  be  de&ed. 
The  resources  committed  to  the  support  function  represent  a  significant  part  of  the  software  life- 
cycle  costs  in  terms  of  both  capital  investments  and  operation  expenses.  Judging  the  optimum 
scale  of  this  investment  involves  trading  off  the  costs  of  support  against  the  operational  benefits  to 
be  derived.  The  supportability  analyses  must  provide  guidance  for  a  support  concept  that  bal¬ 
ances  reliability,  maintainability,  and  operational  effectiveness  with  acceptable  cost  parameters. 

20.4.2  Software  Support  Tasks  and  Initiator  Events 

For  any  computer-based  system  there  will  be  a  number  of  different  situations  that  could  initiate 
the  need  for  software  support  task  activities.  It  is  m^ortant  to  examine  such  support  initiators 
and  the  consequent  support  requirements  at  the  same  time  that  equipment  design  alternatives  are 
being  considered.  The  events  or  situations  that  may  initiate  software  support  task  activities 
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should  be  grouped  according  to  common  operation,  modification,  and  logistics  management  sup¬ 
port  impact.  A  set  of  top-level  software  support  initiator  groups  should  be  defined  against  which 
the  support  requirements  of  the  subject  software  item  may  be  determined.  These  initiator  groups 
should  be  adapted  as  necessary  to  the  individual  nature  of  specific  systems  and  the  impact  of  the 
software  on  system  use  and  mission  capability.  Some  of  the  software  support  tasks  and  possible 
initiator  events  are  illustrated  in  Table  20A. 


TABLE  20A 

SOFTWARE  SUPPORT  TASKS  AND  INITIATOR  EVENTS 

Support  Area 

Support  Task 

Support  Task  Initiator 

Operational 

Installation 

Release  Distribution 

Data  Load  and  /or  Unload 

Mission  Preparation/Completion 

Backup 

Preventive  Maintenance  Schedule 

Failure  Reporting 

System  Failure 

Recovery 

System  Failure 

Training 

Personnel,  System,  Software, 

Procedures,  Update 

Modification 

Corrective  Maintenance 

Software  Failure 

Perfective  Maintenance 

Change  in  User  Functional  or 
Performance  Requirements 

Adaptive  Maintenance 

Change  in  Hardware  or  Commercial 
Software 

Configuration  Management 

Completion  of  New  SW  Version 

Logistics  Management 

Release  Replication 

Field  Loss  of  System  &  Backup 

Release  Distribution 

Release  of  New  SW  Version 

Installation  of  Commercial 
Software 

Release  Distribution 

Help  Desk  Management 

Field  Problem  Query 

Defining  initiator  groups,  conducting  supportability  analyses,  and  identifying  an  appropriate  sup¬ 
port  concept  may  be  carried  out  iteratively  during  the  development  phase  (and  even  the  support 
phase)  of  a  program/project.  Each  iteration  should  build  on  the  previous  analysis  and  use  the  re¬ 
sults  to  modify  or  validate  the  evolving  software  support  concept.  At  the  earliest  development 
stage,  an  analysis  of  support  initiators  should  be  undertaken  as  part  of  the  requirements  identifica¬ 
tion  process.  The  aim  should  be  to  ensure  that  the  software  design  approach  takes  account  of 
what  postdelivery  changes  may  be  anticipated.  The  support  capability  must  be  responsive  and 
efficient  in  satisfying  user  needs  and  minimizing  the  life-cycle  cost  of  support  resources. 
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Design  characteristics  that  affect  software  supportability  include: 

•  design  conplexity  (including  related  attributes  of  software  size,  structure,  and  interre¬ 
lationships), 

•  stability  and  flexibility  of  the  design  itself  and  adequacy  of  documentation, 

•  completeness  of  the  software  development  effort,  and 

•  the  extent  and  in:q)lementation  of  configuration  management  practices  for  both  opera¬ 
tional  and  support  software. 

Other  factors  within  the  development  environment  that  impact  software  supportability  include: 

•  availability  of  qualified  software  personnel, 

•  system  structure  understandabUity, 

•  ease  of  system  handling, 

•  use  of  standardized  programming  languages, 

•  documentation  structure  standardization, 

•  test  case  availability, 

•  built-in  debugging  mechanisms, 

•  availability  of  original  development  documentation  to  the  maintenance  organization,  and 

•  availability  of  appropriate  computer  hardware  to  conduct  maintenance  activities. 

Software  support  includes  support  of  government-developed  software,  contractor-developed 
software,  and  commercial  software.  (Chapter  21  is  devoted  to  the  subject  of  conunercial  and 
nondevelopmental  items.)  The  following  are  issues  to  consider  when  supporting  commercial 
software: 

•  The  acquisition  agent  must  acquire  appropriate  documentation  and  data  rights,  licens¬ 
ing,  and  subscription  services  (such  as  options  to  purchase  or  escrow  proprietary  in¬ 
formation),  which  allows  the  government  to  support  the  software  if  contracted  support 
becomes  unfeasible. 

•  The  Software  Support  Activity  (SAA)  must  maintain  appropriate  licensing  and  sub¬ 
scription  services  (vendor  field  change  orders  and  software  releases)  throughout  the 
life  of  the  system. 

•  Commercial  software  resources  must  not  be  altered  to  preclude  contractor  logistics 
support  or  void  licensing  or  subscription  services. 
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•  The  supporting  command  must  provide  logistics  support  and  provide  a  contract  for 
subscription  services  required  to  update  and  maintain  commercial  software  assets.  It 
must  also  evaluate  operational  and  logistics  impacts  of  change  due  to  subscription- 
related  hardware  and  software  upgrades. 

•  The  operational  command  must  provide  a  technical  review  of  proposed  changes  during 
upgrades  and  changes  to  commercial  software  assets.  It  is  responsible  for  evaluating 
the  effectiveness  and  mission  impact  of  changes  due  to  subscription-related  software 
upgrades. 

20.4.3  Life-Cycle  Support  Strategies 

Life-cycle  support  strategies  ensure  that  the  contractor,  when  developing  the  software,  addresses 
information  and  documentation  management,  quality,  and  verification  procedures.  Typical  life- 
cycle  support  strategies  available  for  source  selection  include  the  following: 

•  Sole  source  (original  contractor^  The  original  contractor  is  awarded  the  software 
support  contract.  The  processes,  products,  and  support  system  are  already  in  place  at 
the  contractor’s  facility  and  typically  are  the  same  as  those  used  during  the  develop¬ 
ment. 

•  Competitive  (support  equipment  orovidedl.  A  competitive  contract  is  awarded;  and 
the  processes,  products,  and  support  systems  are  either  transferred  fi'om  the  original 
contractor  facility  to  the  competing  contractor  or  the  items  are  duplicated.  The  origi¬ 
nal  contractor  can  also  be  a  competitor. 

•  Organic/ contractor  mix.  The  government  and  the  contractor  share  responsibility  for 
software  support.  Each  agent  is  assigned  a  percentage  of  the  software  to  be  sup¬ 
ported.  Typically,  the  government  and  contractor  are  collocated.  The  processes, 
products,  and  support  systems  are  relocated  to  a  government  support  center;  or  the 
items  are  duplicated.  Either  the  original  contractor  or  a  competitive  contractor  will 
share  the  manning  of  the  effort  with  the  government. 

•  Organic.  The  government  assumes  responsibility  for  software  CSCIs.  The  processes, 
products,  and  support  systems  are  relocated  to  a  government  support  center  or  dupli¬ 
cated.  Government,  i.e.,  organic,  personnel  execute  the  support  processes. 

20.4.4  Computer  Resources  Documentation 

Hardware  and  software  support  concepts  should  include  plans  for  upgrades  or  technology  inser¬ 
tion  over  a  nominal  10-year  life  cycle  following  fully  operational  capability. 

DoD  5000.2-R  does  not  require  a  specific  format  for  documenting  software  development  and  lo¬ 
gistics  support  effort.  However,  the  PM  should  oversee  the  creation  of  such  a  document  in  the 
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early  stages  of  system  development.  It  should  clearly  identify  the  computer  resources  of  the  sys¬ 
tem  and  partition  the  system  into  HWCIs  and  CSCIs.  Table  20B  provides  a  guideline  for  a  pro¬ 
posed  system’s  computer  resources  support  documentation.  Although  there  is  no  requirement  for 
a  stand-alone  program  document,  it  is  stiU  a  valuable  management  tool  and  is  recommended  as  such. 


TABLE  20B 

COMPUTER  RESOURCES  SUPPORT  GUIDELINES 

(Optional  Document  -  Notional  Outline) 

Introduction 
Referenced  documents 
Support  information 
Support  environment(s) 

Support  software  required  and  uses  of  each 

Support  hardware  required  and  uses  of  each  and  relationship  to  support  software 

Facilities  required,  including  description  of  purpose,  recommended  location, 
predicted  utilization  rates,  and  special  requirements 

Personnel  requirements,  including  skills,  skill  level,  training,  experience,  and  security 
clearance  requirements. 

Other  required  resources 

Operations,  including  general  usage  instructions  such  as  procedures  for  initiation,  op¬ 
eration,  and  monitoring  in  the  support  environment 

•  Initiation  of  the  support  environment 

•  General  operation  of  the  support  environment 

•  Monitoring  operation  of  the  support  environment 

Administration,  including  description  of  the  management  and  control  functions, 
which  include  access,  security,  and  access  to  storage  of  information 

Software  modification 
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TABLE  20B  (Continued) 

COMPUTER  RESOURCES  SUPPORT  GUIDELINES 
(Optional  Document  -  Notional  Outline) 


Software  integration  and  testing 

System  and  software  generation  (new  operational  software)  software  quality 
evaluation 

Corrective  action  system,  i.e.,  a  description  of  the  recommended  method  for 
closed-loop  identification  and  resolution  of  operational  software  problems,  both 
modified  and  unmodified 

Configuration  management,  describing  the  procedures  to  be  used  to  maintain  strict 
configuration  management  of  operational  software,  both  modified  and  unmodified. 

Simulation,  describing  any  simulation  software  or  hardware  that  is  required  to 
support  software  maintenance 

Emulation  (as  above) 

Reproduction  Procedures 

Distribution  Procedures 

Training 

Predicted  level/tempo  of  changes,  describing  and  identifying  deficiency  corrections 
and  plans  for  upgrades  or  technology  insertion  over  a  nominal  10-year  life  cycle 
following  fuUy  operational  capability. 


20.5  SOFTWARE  COST  AND  RESOURCE  ESTIMATION^* 

One  of  the  most  challenging  tasks  in  project  management  is  to  reliably  estimate  the  size  of  the 
software  product  and  resources  needed  to  produce  the  product.  The  software  estimation  process 
provides  the  project  manager  with  the  estimates  to  develop  the  project  schedule,  to  apply  re¬ 
sources,  and  to  determine  the  probable  cost  of  the  project. 


*  This  section  based  on  the  “Report  on  Project  Management  and  Software  Cost  Estimation  Technologies,”  April 
1995,  by  Software  Technology  Support  Center  (STSC),  Hill  AFB,l)T  84056,  Phone  801-777-7703 


20-10 


This  section  discusses  the  software  estimation  process,  software  tools  that  are  available  for  sof- 
ware  estimation,  benefits  of  software  estimation,  and  trends  in  software  estimation  technology. 

20.5.1  Software  Estimation  Process 

Software  estimation  should  be  approached  as  a  major  process;  it  should  be  well  planned,  reviewed 
often,  and  continually  updated.  The  basic  steps  required  to  accomplish  software  estimation 
foUow: 

•  identify  project  objectives  and  requirements; 

•  plan  the  activities; 

•  estimate  product  size  and  complexity; 

•  estimate  effort,  cost,  and  resources; 

•  develop  projected  schedule; 

•  compare  and  iterate  estimates;  and 

•  follow  up. 

Further  information  regarding  each  of  these  steps  is  available  in  the  “Report  on  Project  Manage¬ 
ment  Software  Cost  Estimation  Technologies,”  mentioned  in  the  footnote  below. 

20.5.2  Software  Estimation  Methods 

The  following  five  methods  have  been  used  for  many  years.  Typically,  in  the  past,  these  methods 
have  been  used  without  conputer-based  software  estimation  tools.  Now,  software  estimation 
tools  are  available  that  incorporate  these  methods: 

•  Analogy  Method.  This  method  conpares  the  proposed  project  to  previously  completed, 
similar  projects  where  actual  project  development  information  is  known.  Data  from  the 
completed  projects  are  used  to  estimate  the  proposed  project.  The  method’s  main 
strength  is  that  the  estimates  are  based  on  actual  project  data  and  past  experience.  The 
analogy  method’s  limitations  are  that  similar  projects  may  not  exist  or  that  the  accuracy 
of  available  historical  data  may  be  suspect.  For  example,  many  DoD  weapon  system 
software  projects  do  not  have  historical  precedents. 

•  Bottom-up  Method.  This  method  estimates  each  component  of  the  software  project 
separately  then  combines  the  results  to  produce  an  estimate  of  the  entire  project.  Ad¬ 
vantages  of  this  method  are  listed  below: 

—  It  provides  a  more  detailed  and  accurate  basis  for  estimation  because  it  deals  with 
low-level  components. 
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It  supports  project  tracking  more  directly  than  other  methods  because  its  estimates  usu¬ 
ally  address  each  activity  within  each  phase  of  the  software  development  life  cycle. 


•  Top-down  Method.  This  method  of  estimating  starts  with  the  overall  characteristics  of 
the  software  project.  The  project  is  then  partitioned  into  lower-level  components  and 
life-cycle  phases.  This  method  is  more  applicable  to  early  estimations  when  only  global 
properties  are  known.  Advantages  of  this  method  are  shown  below: 

—  It  considers  system-level  activities  (integration,  documentation,  projects  control, 
configuration  management,  etc.),  many  of  which  may  be  overlooked  in  other  esti¬ 
mation  methods. 

—  It  is  usually  faster  and  easier  to  implement  than  the  bottom-up  method. 

—  It  requires  minimal  project  detail. 

This  method  has  disadvantages:  (1)  it  tends  to  be  less  accurate  than  other  methods;  (2) 
it  tends  to  overlook  lower-level  components  and  technical  problems;  and  (3)  it  provides 
very  little  detail  for  justifying  estimates. 

•  Expert  Judgment  Method.  This  method  uses  the  experience  and  understanding  of  hu¬ 
man  experts  to  provide  the  project  estimates.  An  advantage  of  this  method  is  the  expe¬ 
rience  fi’om  past  projects  that  the  expert  brings  to  the  proposed  project.  The  expert  also 
can  factor  in  project  impacts  caused  by  new  technologies,  applications,  and  languages. 
Disadvantages  are:  (1)  estimates  can  be  no  better  than  the  expertise  and  judgment  of  the 
expert;  and  (2)  it  can  be  difficult  to  document  the  factors  used  by  the  expert  who  con¬ 
tributes  to  the  estimate.  The  best  use  of  expert  judgment  is  as  a  complement  to  other 
estimation  methods. 

•  Algorithmic  Method.  This  method  uses  mathematical  formulas  to  make  software  esti¬ 
mates.  The  formulas  are  derived  form  research  and  historical  data  and  use  inputs  such 
as  source  lines  of  code  (SLOC),  number  of  functions  to  perform,  and  other  cost  factors 
including  programming  language,  design  methodology,  skill  levels,  and  risk  assessments. 
Advantages  of  this  method  include  the: 

—  ability  to  generate  repeatable  results; 

—  ease  in  modifying  input  data; 

—  ease  in  revising  and  customizing  formulas;  and 

—  ability  to  better  understand  the  estimation  methods  sinee  the  formulas  can  be  analyzed. 

However,  the  results  can  be  questionable  when  estimating  future  projects  that  use  new  technolo¬ 
gies.  The  formulas  generally  are  unable  to  deal  with  conditions  such  as  exceptional  personnel, 
exceptional  teamwork,  and  exceptional  matches  between  skill  levels  and  tasks.  Additionally,  al¬ 
gorithms  are  usually  developed  within  companies  for  internal  use  and  may  be  more  reflective  of  a 
company’s  performance  characteristics  than  of  software  development  in  general;  also,  they  may  be 
proprietary. 
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20.5.3  Risks 


All  known  risks  associated  with  a  software  development  project  should  be  defined  and  weighed, 
and  impacts  to  project  costs  should  be  determined.  This  information  should  always  be  included  as 
part  of  the  software  estimation  process.  Poor  software  estimates  generally  result  fi-om  four  major 
risk  areas: 

•  underestimation  of  the  software  size, 

•  instability  in  the  development  environment  or  processes, 

•  misalignment  of  staff  skills  to  required  tasks,  and 

•  requirements  growth  during  the  software  development  life  cycle. 

20.5.4  Trends 

New  software  development  processes  and  products  are  overcoming  traditional  software  develop¬ 
ment  methodologies.  The  growing  use  of  fourth-generation  languages,  commercial  software,  re¬ 
use,  and  object-oriented  development,  to  name  a  few,  is  making  significant  changes  in  the  way 
applications  are  developed  within  organizations.  Consequently,  software  estimation  models  are 
changing;  and  new  approaches  and  greater  flexibility  are  required  in  the  models. 

20.5.5  Typical  Input  Data  for  a  Top-Down  (Parametric)  Cost  Model 

This  section  illustrates  the  type  of  data  that  would  be  entered  in  a  top-down  software  cost  model. 
For  illustrative  purposes  only,  the  example  used  is  taken  fi’om  the  SEER-SEM  model,  one  of 
many  listed  in  Table  20D  at  the  end  of  this  chapter. 

•  Software  Configuration  Management.  Enter  the  average  monthly  labor  rate  for  software 
configuration  management  personnel  only. 

•  Software  Data  Preparation.  Enter  the  average  monthly  labor  rate  for  software  data  prepa¬ 
ration  personnel  only. 

•  Software  Test.  Enter  the  average  monthly  labor  rate  for  software  test  personnel  only. 

•  Software  Maintenance.  Parameters  included  in  this  category  are: 

—  Years  of  Maintenance. 

—  Separate  Sites. 

—  Maintenance  Growth  over  Life. 

—  Personnel  Differences. 

—  Development  Environment  Differences. 

—  Annual  Change  Rate. 

—  Maintenance  Level. 
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—  Min  Maintenance  Staff  (Optional). 

—  Max  Maintenance  Staff  (Optional). 

—  Maintenance  Monthly  Labor  Rate. 

—  Additional  Annual  Maintenance  Cost. 

—  Maintenance  Start  Date. 

—  Percent  To  Be  Maintained. 

—  Maintain  Total  System. 

•  Years  of  Maintenance.  Number  of  years  for  which  software  maintenance  costs  will  be  es¬ 
timated.  Maintenance  begins  when  operational  test  &  evaluation  is  completed. 

•  Separate  Sites.  Number  of  separate  operational  sites  where  the  software  wiU  be  installed 
and  users  will  have  an  input  into  system  enhancements. 

•  Maintenance  Growth  over  Life.  The  anticipated  size  growth  from  the  point  immediately 
after  the  software  is  turned  over  to  maintenance  to  the  end  of  the  maintenance  cycle. 
Software  growth  may  include  additions  of  new  functionality.  Major  enhancements  should 
be  modeled  separately  as  new  developments  or  incremental  builds. 

•  Personnel  Differences.  Rates  the  maintenance  personnel’s  capabilities  and  experience  in 
conparison  to  the  development  personnel’s  capabilities  and  experience.  If  maintenance 
only  is  being  estimated  as  a  separate  CSCI,  this  parameter  should  be  set  to  Nominal;  and 
the  Personnel  Capabilities  and  Experience  parameters  should  be  rated  individually. 

•  Development  Environment  Differences.  Rates  the  quality  of  the  maintenance  environment 
in  comparison  to  the  tools  and  practices  used  in  the  development  environment.  If  mainte¬ 
nance  is  being  estimated  as  a  separate  CSCI,  this  parameter  should  be  set  to  Nominal;  and 
Development  Support  Environment  parameters  should  be  rated  individually. 

•  Annual  Change  Rate.  Average  percentage  of  the  software  impacted  by  software  mainte¬ 
nance  and  sustaining  engineering  per  year.  This  could  include  changes,  revalidation,  re¬ 
verse  engineering,  re-documentation,  minor  changes  for  new  hardware,  or  re-certification. 

•  Maintenance  Level  (Rigor).  This  parameter  rates  the  thoroughness  with  which  mainte¬ 
nance  activities  will  be  performed.  For  example: 

Rating  Description 

Very  High  Thorough  maintenance  for  all  types  of  software  maintenance  activities,  including 
regular  documentation  updates.  Software  maintenance  is  well  planned  in  both 
the  long  and  short  term  with  frequent  reviews  of  priorities.  Dedicated  staff  as¬ 
signed  for  maintenance.  Software  will  remain  useful  for  users  and  will  not  de¬ 
generate  over  time. 

High  Complete  maintenance  including  maintenance  planning  and  priority  review. 

Software  documentation  is  updated  on  a  semi-regular  basis.  Software  will  not 
degenerate  over  time. 
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Nominal  Average  maintenance  activity.  Short-term  planning  and  prioritization  of  mainte¬ 
nance  activity.  Documentation  is  updated  less  than  once  a  year  (change  pages 
and  addenda).  Software  wftl  become  less  useful  as  more  time  goes  by. 


Low  Basic  maintenance  with  most  activity  being  reactive  to  emergencies  and  problems 

as  they  arise.  No  planning  of  maintenance  activity.  Documentation  is  updated 
only  with  change  pages  and  addenda.  Software  will  degenerate  over  time. 

Very  Low  Bare-bones  maintenance.  Nondedicated  team  doing  emergency  fixes.  Mainte¬ 
nance  is  performed  on  an  ad  hoc,  sporadic  basis.  Little  to  no  documentation  up¬ 
date.  Software  will  degenerate  rapidly.  May  also  represent  sustained  engineer¬ 
ing  efibrt  of  a  delivered  incremental  subsequent  build. 


•  Mainfenanrp  Staffing.  This  is  the  minimum  number  of  personnel  who  will  be  assigned  to 
maintain  the  software.  Use  this  parameter  for  fixed  staffing  or  level  of  effort  maintenance. 

•  Maintenance  Monthly  Labor  Rate.  This  is  the  average  monthly  labor  rate  for  maintenance 
personnel. 

•  Additional  Annual  Maintenance  Cost.  This  is  any  annual  throughput  maintenance  cost. 

•  Percent  To  Be  Maintained.  Percentage  of  the  total  that  will  be  maintained.  For  example, 
if  part  of  the  software  is  in  a  read  only  memory  and  cannot  be  changed,  exclude  this  part 
of  the  computer  program  fi:om  software  maintenance  costs  by  reducing  this  percentage. 

•  Maintain  Total  System.  Determines  whether  total  size  or  effective  size  should  be  used  to 
estimate  maintenance. 

•  Software  Code  Metrics.  This  parameter  category  allows  user  inputs  into  various  software 
code  metrics.  These  metrics  are  used  to  calculate  the  reliability  of  the  produced  code. 
Since  these  metrics  are  normally  only  available  after  a  development  is  completed,  some 
models  will  automatically  estimate  these  metrics  internally  if  no  entries  are  given.  Because 
of  this,  these  code  metrics  should  only  be  entered  if  detailed  and  accurate  measurements  of 
the  actual  code  are  available  fi'om  which  to  collect  these  metrics.  Detailed  definitions  of 
these  are  published  in  IEEE  publications  as  well  as  most  textbooks  encompassing  software 
metrics. 


20.5.6  Typical  Output  Data  for  a  Top-down  (Parametric)  Model 

Table  20C  is  an  example  of  the  output  data  from  a  parametric  software  cost-estimating  model.  In 
order  to  parallel  the  input  data  in  section  20.5.5,  this  example  is  also  extracted  from  the  SEER- 
SEM  model.  However  to  reiterate,  SEER-SEM  is  but  one  of  the  many  models  listed  in  Table 
20D  and  is  used  for  illustrative  purposes  only. 
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Table  20C 

Illustrative  Example  of  Maintenance  Effort  and  Cost  by  Year 


Base  Year;  1994 
Fiscal  Year  Start  Month;  1 


Fiscal 

Average 

Effort  Months 

Base  Year 

Base  Year 

Year 

Staff  Level 

Correct 

Adapt 

Perfect 

Enhance  Total 

Cumulative  Cost 

Cumulative 

1999 

6.4 

22.7 

3.2 

20.2 

2.8 

49.9 

49.0 

720,887 

720,887 

2000 

5.5 

26.4 

6.9 

24.3 

8.3 

65.9 

114.9 

968,532 

1,689,419 

2001 

3.7 

9.6 

9.1 

12.8 

12.6 

44.1 

159.0 

648.532 

2,337,877 

2002 

2.9 

4.7 

8.9 

9.2 

12.6 

35.3 

194.4 

519,332 

2,857,209 

2003 

2.9 

4.7 

8.9 

9.2 

12.6 

35.3 

229.7 

519,332 

3,376,541 

2004 

2.9 

4.7 

8.9 

9.2 

12.6 

35.3 

265.0 

519,332 

3,895,873 

2005 

2.9 

4.7 

8.9 

9.2 

12.6 

35.3 

300.4 

519,332 

4,415,205 

2006 

2.9 

4.7 

8.9 

9.2 

12.6 

35.3 

335.7 

519,332 

4,934,537 

2007 

2.9 

4.7 

8.9 

9.2 

12.6 

35.3 

371.0 

519,332 

5,453,869 

2008 

2.9 

4.7 

8.9 

9.2 

12.6 

35.3 

406.3 

519,332 

5,973,201 

2009 

2.9 

4.7 

8.9 

3.4 

4.6 

12.9 

419.2 

189,113 

6,162,315 

20.5.7  Software  Estimation  Tools 

Software  estimation  tools  do  not  guarantee  good  software  estimates.  If  unreliable  software  size 
estimates  and  attribute  ratings  are  input,  then  poor  estimates  will  result.  This  is  known  as  the  gar¬ 
bage  in/garbage  out  or  GIGO  principle.  Good  estimates  are  dependent  on  collecting,  refining, 
and  maintaining  historical  data  from  current  and  past  projects  to  provide  the  necessary  inputs  re¬ 
quired  for  the  software  estimation  tools.  The  software  development  organization  should  establish 
a  staff  that  is  thoroughly  trained  in  the  software  estimation  process  and  use  of  available  estimation 
tools;  they  should  be  involved  in  aU  software  estimates  for  the  organization.  Experience  and  ex¬ 
isting  tools  dictate  what  software  development  information  needs  to  be  maintained. 

Table  20D  lists  some  of  the  available  cost  estimation  tools  available  to  the  PMO  staff. 


20-16 


TABLE  20D 

SOFTWARE  COST  ESTIMATION  TECHNOLOGY  PRODUCT  LIST 


PRODUCT 

VENDOR 

PLATFORM 

AEM 

Koch  Productivity  Consulting 
410-838-8721 

DOS/Windows,  OS2 

CA-Estimacs 

Computer  Associates  Int.,  Inc. 
201-585-6720 

PC  (286, 386, 486,  etc.)  MS-DOS,  Windows  3.x 

CA-FPXpert 

Computer  Associates  Int.,  Inc. 
201-585-6720 

MS-DOS 

CA-Metrics 

Computer  Associates  Int.,  Inc. 
201-585-6720 

IBM,  MS-DOS 

CA-Planmacs 

Computer  Associates  Int.,  Inc. 
201-585-6720 

PC-MS/DOS 

CA-Project  Navigation 

Computer  Associates  Int.,  Inc. 
201-585-6720 

MS-DOS 

CB  COCOMO 

Decisioneering,  Inc. 

303-337-3531 

Mac/Windows,  Excel,  Lotus  1-2-3 

CHECKPOINT 

Software  Productivity  Research,  Inc. 
617-273-0140 

IBM  or  compatible  (386  min)  HP7XX  &  8XX,  Sun 
SPARC,  Windows  Rel.  3 

COCOMOID 

Air  Force  Cost  Center 

513-257-4624 

MS-DOS 

CoCoPro 

Iconix  Software  Engineering,  inc. 
310458-0092 

Macintosh 

COSTAR 

Softstar  Systems 

603-672-0987 

DEC  VAX,  VAXstation,  Micro  VAX/VMS, 

PC-MS/DOS 

COSTMODL 

COSMIC 

706-542-3265 

IBM,  HP7XX  &  8XX,  Sun  SPARC,  Motorola  MPC 
(88000  or  88100) 

Crystai  Ball 

Decisioneering 

303-337-3531 

Mac/Windows 

GECOMO  Plus 

Marconi  Systems  Technology 
703-263-1260 

VMS,  Unix  OSF  Motif,  Windows 

Micro  Man  ESTI-MATE 

Protellicess  Software 

310-393-4552 

MS-DOS,  PC-Windows 

PRICES 

Martin  Marietta  PRICE  Systems 
800437-7423 

Unix/Motif  or  MS  Windows 

Project  Base 

Kapur  International,  Inc. 

510-275-8000 

PC/MS-DOS 

Project  Bridge 

Applied  Business  Technology  Corp. 
8004^724 

MS-DOS/MS  Win 

REVIC 

Air  Force  Cost  Analysis  Agency 
703-746-5865 

MS-DOS 
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TABLE  20D  (Continued) 

SOFTWARE  COST  ESTIMATION  TECHNOLOGY  PRODUCT  LIST 


PRODUCT 

VENDOR 

PLATFORM 

SASET 

Air  Force  Cost  Analysis  Agency 
703-746-5865 

MS-DOS 

SECOMO 

irr  Research  Institute 

315-339-7004 

IBM  PC,  MS-DOS,  VAX/VMS  3.2+ 

SEER-HLC 

Galorath  Associates,  Inc. 

310-670-3404 

PC-MS/DOS 

SEER-SEM 

Galorath  Associates,  Inc. 

310-670^ 

IBM  PC,  Macintosh,  SUN,  Windows  3.1  or  higher, 
Sys  7,  Unix 

SEER-SSM 

Galorath  Associates,  Inc. 

310-670-3404 

IBM  PC,  DOS  3.0+ 

SIZE  Planner 

Quantitative  Software  Mgt.,  Inc. 
703-7904)055 

IBM,  PC/Windows  3.1,  SUN 

SIZE  Pius 

Marconi  Systems  Technology 
703-263-1260 

VMS,  Unix  OSF  Motif,  X-Win 

SLIM 

Quantitative  Software  Management,  Inc. 
703-790-0055 

IBM  PC/Windows  3.1,  Windows  NT,  Windows  for 
Workshops,  OS/2 

SLIM  Control 

Quantitative  Software  Management,  Inc. 
703-7904)055 

IBM  PC,  Windows  for  Workgroups,  Windows  NT, 
OS/2 

SPQR/20 

Software  Productivity  Research,  Inc. 
617-273-0140 

MS-DOS 

SWAN 

IIT  Research  Institute 

315-339-7004 

MS-DOS 

VAX  Software  Project 
Manager  (V.1^) 

Digital  Equipment  Corp. 

800-3444825 

DEC  VAX,  Micro  VAX,  VAXstation/VMS,  Micro 

VMS 
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21 

COMMERCIAL  AND 
NONDEVELOPMENTAL 
ITEM  (NDI)  LOGISTICS 

‘To  provide  for  the  rapid  delivery  of  major  acoustic  improvements  to  the  SSN688,  SSN  6881 
and  SSBN  726  class  submarines,  we  have  implemented  a  Program  entitled  Acoustics  Rapid 
COTS  Insertion  (A-RCI).  This  four-phased  plan  will  reduce  the  time  for  obtaining  opera¬ 
tional  value  from  demonstrated  technologies.  ....  A-RCI  will  implement  a  COTS  based  open 
system  approach  utilizing  commercial  processing  capacity,  which  has  substantial  growth  po¬ 
tential.  Further,  A-RCI  results  in  space  and  weight  reduction,  reduced  cycle  time  for  future 
upgrades  and  development  cost  savings” 

ASN(RDA),  before  the  Subcommittee  on  Seapower 
of  the  Senate  Armed  Services  Committee,  1996 


21.1  DEFINITIONS 

Definitions  of  Commercial  Items  (CIs)  and  Nondevelopmental  Items  (NDIs)  describe  a  broad, 
generic  area  that  covers  material  available  from  a  variety  of  sources  with  little  or  no  development 
effort  required  by  the  government.  These  acquisitions  provide  major  benefits  as  well  as  chal¬ 
lenges  to  the  systems  acquisition  process  and  the  user.  Benefits  include:  quick  response  to  op¬ 
erational  needs;  elimination  or  reduction  of  research  and  development  costs;  application  of  state- 
of-the-art  technology  to  current  requirement;  and  reduction  of  technology,  cost,  and  schedule  risks. 

These  acquisitions  present  challenges  including  the  possibility  that  items  developed  for  needs 
other  than  DoD’s  may  fail  to  meet  all  of  the  user  requirements  and  mission-performance  tradeoffs 
that  are  required  to  gain  the  advantages  of  pursuing  these  alternatives.  Additional  challenges  in¬ 
clude  providing  logistics  support,  product  modifications,  and  continued  product  availability.  Cl 
and  NDI  acquisitions  benefit  the  systems  acquisition  process  in  reducing  risk  and  development 
costs.  These  benefits  may  be  offset,  unless  carefully  balanced  by  intelligent  performance  trade¬ 
offs.  The  following  definitions  are  provided  by  DoD  5000.2-R  (15  March  1996). 

21.1.1  Commercial  Item 

A  Cl  is  defined  as  any  item,  other  than  real  property,  that  is  of  a  type  customarily  used  for  non¬ 
governmental  purposes  and  that: 

•  has  been  sold,  leased,  or  licensed  to  the  general  public; 

•  has  been  offered  for  sale,  lease,  or  license  to  the  general  public;  and 
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•  has  evolved  through  advances  in  technology  or  performance  that  are  not  yet  available 
in  the  commercial  marketplace,  but  this  item  will  be  available  in  the  commercial  mar¬ 
ketplace  in  time  to  satisfy  the  delivery  requirements  stipulated  under  a  government  so¬ 
licitation. 

Also  included  in  the  definition  are  services  in  support  of  a  Cl,  or  a  type  offered  and  sold  com¬ 
petitively  in  substantial  quantities  in  the  commercial  marketplace  based  on  established  catalog  or 
market  prices  for  specific  tasks  performed  under  standard  commercial  terms  and  conditions.  This 
does  not  include  services  that  are  sold  based  on  hourly  rates  without  an  estabhshed  catalog  or 
market  price  for  a  specific  service  performed  under  standard  commercial  terms  and  conditions. 
Also,  it  does  not  include  services  that  are  sold  based  on  hourly  rates  without  an  established  cata¬ 
log  or  market  price  for  a  specific  service  performed. 

21.1.2  Modified  Commercial  Item 

A  modified  Cl  is  any  modified  item  that  is  customarily  available  in  the  commercial  marketplace 
and  that  is  made  to  meet  Federal  Government  requirements.  Such  modifications  are  considered 
minor  if  the  change  does  not  significantly  alter  the  non-governmental  function,  essential  item  or 
component,  physical  characteristics,  and  the  purpose  of  the  process.  Factors  to  be  considered  in 
determining  whether  a  modification  is  minor  include  the  value  and  size  of  the  modification  and  the 
conparative  value  and  size  of  the  final  product.  Dollar  values  and  percentages  may  be  used  as 
guideposts,  but  they  are  not  conclusive  evidence  that  a  modification  is  minor. 

21.1.2.3  Nondevelopmental  Item 

A  nondevelopmental  item  is: 

•  any  previously  developed  supply  item  used  exclusively  for  governmental  purposes  by 
an  agency,  state,  local  government,  or  a  foreign  government  that  has  a  mutual  defense 
cooperation  agreement  with  the  United  States; 

•  any  item  that  fits  the  first  description  above,  and  that  requires  only  minor  modification 
or  modifications  of  the  type  customarily  available  in  the  commercial  marketplace  in 
order  to  meet  the  requirements  of  the  procuring  department  or  agency;  and 

•  any  item  that  is  not  in  use  and  that  fits  the  descriptions  above. 

A  succinct  version  of  this  definition  is  provided  in  Table  21  A. 

21.2  BACKGROUND 

Since  the  early  1970s,  several  studies  have  supported  the  increased  use  of  NDIs  by  DoD.  The 
President’s  Blue  Ribbon  Commission  on  Defense  Management  (the  Packard  Commission)  was  a 
major  turning  point  in  the  history  of  NDI  acquisition.  The  1986  report  reviewed  and  brought  new 
enphasis  to  earlier  studies  advocating  NDIs.  The  Commission  took  the  position  that  “DoD 
should  make  greater  use  of  conponents,  systems,  and  services  available  off  the  shelf.  It  should 
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develop  new  or  custom-made  items  only  when  it  has  been  clearly  established  that  those  readily 
available  are  clearly  inadequate  to  meet  military  requirements.”  Regarding  military  specifications, 
the  commission  asserted  that  products  developed  strictly  for  mihtary  use  and  to  military  specifica¬ 
tions  generally  cost  more  than  commercial  counterparts  and  that  adherence  to  these  specifications 
was  often  needless  and  wasteful.  If  there  is  an  available  commercial  counterpart,  it  recommended 
that  the  Defense  Acquisition  Executive  (DAE)  require  program  directors/managers  to  receive  a 
waiver  before  using  a  product  made  to  military  specifications.  The  commission  findings  were  echoed 
again  in  the  1989  National  Security  Review  on  Defense  Management.  Finally,  the  Congress  has  im¬ 
plemented  specific  language  concauing  use  of  NDIs  in  recent  authorization  and  appropriation  acts  in 
order  to  ensure  that  DoD  addresses  its  NDI  concerns.  For  its  part,  DoD  has  provided  new  guidance 
on  NDI  acquisition  in  DoDD  5(X)0.1  and  DoD  5()00.2-R  of  15  March  1996. 


Table  21A 

NONDEVELOPMENTAL  ITEM;  DEFINITION 

•  Previously  developed  item  used  exclusively  for  govern¬ 
mental  purposes  by: 

-  Federal  Agency 

-  State  or  Local  Government 

-  Foreign  Government 

•  Same  as  above  but  with  modifications  or  soon  in  use. 


21.2.4  Requirements  Generation 

The  conception  of  any  acquisition  program  lies  in  the  identification  of  a  need  for  a  system  to  meet 
a  military  requirement.  This  need  or  requirement  is  expressed  by  the  using  Commands  in  terms  of 
operational  requirements  documents.  Once  these  requirements  are  generated  and  validated,  the 
developing  or  procurement  commands  are  tasked  to  find  the  system  or  component  that  will  meet 
the  requirement.  DoD  5000.2-R  states  that  the  Program  Manager  (PM)  shall  consider  all  of  the: 

“...prospective  sources  of  supplies  and/or  services  that  can  meet  the  need,  both 
domestic  and  foreign.  CIs  and  NDIs  shall  be  considered  as  the  primary  source  of 
supply. 

“Market  research  and  analysis  shall  be  conducted  to  determine  the  availability  and 
suitability  of  existing  CIs  and  NDIs  prior  to  the  commencement  of  a  development 
effort,  during  the  development  effort,  and  prior  to  the  preparation  of  any  product 
description.  The  PM  shall  define  requirements  (including  hardware,  software, 
standards,  data,  and  automatic  test  systems)  in  terms  that  enable  and  encourage 
offerors  of  CIs  and  NDIs  an  opportunity  to  compete  in  any  procurement  to  fill 
such  requirements. 
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‘The  PM  shall  require  prime  contractors  and  subcontractors  at  all  levels  to  incor¬ 
porate  CIs  and  NDIs  or  components  of  items  supplied  and  modify  requirements  to 
the  maximum  extent  practicable,  to  ensure  that  the  requirements  can  be  met  by  CIs 
and  NDIs.  For  ACAT  I  and  lA  programs,  while  few  CIs  meet  requirements  at  a 
system  level,  numerous  commercial  conponents,  processes,  and  practices  have  ap¬ 
plication  to  DoD  systems.  CIs  supplied  shall  be  based  on  non-governmental  stan¬ 
dards  and  Cl  descriptions  to  the  maximum  extent  practicable.  Preference  shall  be 
given  to  the  use  of  CIs  first  and  nondevelopmental  items  second.  However,  the 
overriding  concern  is  to  use  the  most  cost-effective  source  of  supply.  Table  21B 
shows  the  hierarchy  of  solutions  to  a  mission  need. 

“Use  of  CIs  or  NDIs  does  not  exempt  the  PM  fi'om  complying  with  environmental 
requirements,  unless  exempted  by  statute.” 


Table  21B 

HIERARCHY  OF  SOLUTIONS  TO  A  MISSION  NEED 

1.  Nonmateriel  solution:  change  in  doctrine,  operational  concept, 
tactics,  training  and/or  organization 

2.  Use  or  modification  of  an  existing  U.S.  Military  System 

3.  Use  or  modification  of  an  existing  commercially  developed  or  allied 
system  that  fosters  a  nondevelopmental  acquisition  strategy 

4.  Cooperative  R&D  program  with  allies 

5.  New  Joint-Service  developmental  program 

6.  New  Service-unique  development  program 


21.3  THE  LOGISTICS  CHALLENGE  IN  COMMERCIAL/NDI  ACQUISITION 

Effective  logistics  poses  a  challenge  in  developmental  programs,  even  with  all  the  training  and 
guidance  that  acquisition  personnel  receive.  Ensuring  that  logistics  is  handled  effectively  in  a 
commercial/NDI  acquisition  can  be  a  significantly  more  difficult  challenge  to  materiel  acquisition 
personnel  beeause  of  the  differences  in  the  commercial/NDI  acquisition  process.  Some  of  the  key 
differences  are  shown  in  Table  21C.  Since  the  acquisition  lead  time  is  reduced,  there  is  less  time 
available  to  plan  for  and  develop  logistics  support.  Those  logistics  activities  that  normally 
would  occur  during  the  Program  Definition  and  Risk  Reduction  (PDRR)  and  the  Engineering  and 
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Table  21C 

COMPARING  CONVENTIONAL  AND 

COMMERCIAL/NDI  LOGISTICS  MANAGEMENT  ACTIONS 

Logistics 

Management 

Actions: 

Conventional 
(New  Development) 

Commercial/ 
Nondevelopmental  Item 

Define 

No  use  data,  requires  conceptual/ 
engineering  skills 

Fully  defined  support  structure  and 
extensive  use  data  available 

Advocate 

Analytical  studies 

Market  research  and  analysis 

Influence 

Design  incomplete  -  considerable 
opportunity 

Design  completed  —  no  opportunity 

Refine 

Challenging,  but  possible  to  refine 
logistics  at  same  pace  as  IPT 

Need  additional  time  to  refine 
logistics  if  item  is  used  in  new 
environment 

Foster  T&E 

TEMP  interface  and  $$  will 
accomplish  this 

Inputs  to  test  plan  first  require  com- 
mercial/NDI  support  planning 

Acquire 

Configuration  instability  can 
hamper  efforts 

Stable  configuration  and  use  data 
make  the  job  relatively  easy 

Provide 

Start  of  lessons-leamed  process 

Extensive  set  of  (non-proprietary, 
hopefully)  lessons  learned  available 

Improve 

Modifications  and  improvements 
are  norm  as  technology  advances 

Immediate  improvement  renders  Acq 
Strategy  “Modified  Commercial” 

Manufacturing  Development  (EMD)  phases  must  be  accelerated  to  ensure  effective  support  for 
that  item.  Unlike  a  developmental  item,  with  commercial/NDI  there  may  be  support  in  place  as 
wen  as  “real”  reliability  data  and  training.  These  items  are  being  used,  broken,  and  fixed.  Addi- 
tionaUy,  logistics  support  may  be  impacted  adversely  by  proliferation  of  hardware  and  software 
since  DoD  may  not  be  acquiring  sufficient  technical  data  and  technical/data  rights  to  maintain 
configuration  control  of  CIs.  Also,  the  influence  DoD  has  on  the  supplier  may  be  hmited  by  its 
customer  status. 

21.3.1  Meeting  the  Challenge 

The  logistics  problems  involved  with  commercial/NDI  acquisition  can  be  overcome,  just  as  they 
can  be  overcome  in  a  traditional  developmental  acquisition.  Acquisition  personnel  must  be  sensi- 
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live  to  problems  and  ensure  they  are  addressed  early  in  the  acquisition  process.  They  must  under¬ 
stand  implementing  effective  logistics,  for  commercial/NDI  will  probably  require  a  departure  from 
“normal”  procedures  of  a  developmental  item’s  acquisition.  Tradeoffs  also  must  be  seriously  con¬ 
sidered  when  deciding  to  adopt  a  commercial/NDI  acquisition  strategy. 

DoD  5000.2-R  directs  each  PM  to  develop  and  document  an  acquisition  strategy  that  will  serve  as 
the  roadmap  for  program  evaluation  from  program  initiation  through  postproduction  support. 

The  acquisition  sfrategy  should  state  whether  organic,  contractor,  or  a  mix  of  organic/contractor 
logistics  support  is  the  most  cost-effective  and  operationally  effective  approach  to  support  the 
item.  Appropriate  tradeoff  analyses  should  be  conducted  to  arrive  at  the  most  cost-effective  and 
operationally  effective  support  strategy.  Interim  contractor  support,  incremental  (block)  devel¬ 
opment  and  fielding  strategies,  lifetime  contractor  logistics  support,  or  full  organic  logistics  sup¬ 
port  shall  be  considered  and  planned  during  the  development  of  the  acquisition  strategy  and  defi- 
nitized  in  the  solicitation.  The  departure  from  “normal”  procedures  or,  rather,  the  inability  to  de¬ 
part  from  them  was  highlighted  in  a  1991  National  Security  Industrial  Association  study,  “Com¬ 
mercial  Off-the-ShelfrNondevelopmental  Items  (COTS/NDI)  Study,”  as  follows: 

“It  is  evident  that  the  logisticians... have  reviewed  and  studied  the  COTS/NDI  issue. 

Apparently  because  of  their  paradigms,  the  results  continue  to  come  out  the  same, 
namely,  that  the  “standard”  way  of  doing  business  should  not  change.  Information  re¬ 
ceived  from  that  community  leads  to  the  conclusion  that  the  only  way  to  go  is  buy 
maintenance  and  provisioning  data  and  train  Army  military  and  civilians  for  mainte¬ 
nance  support... 

“What  this  bears  out  is  that  acquisition,  fielding,  and  sustainment  of  COTS/NDI 
remains  a  serious  problem  for  the  U.S.  Army.  A  major  change  in  culture  is  neces¬ 
sary  ,  and  that  cannot  happen  quickly.  The  current  methods,  procedures,  and  cuts 
have  been  grown,  cultivated,  and  taught  since  the  end  of  World  War  II.”' 

The  study  explains  the  possible  reason  for  this  situation: 

“Life-cycle  support,  worldwide,  is  very  inportant  to  the  Army,  as  the  Army  can  be 
required  to  deploy  to  any  location  in  the  world  on  short  (hours)  notice.  It  must  be 
able  to  keep  its  equipment  and  systems  operational  so  as  to  ensure  successful  mis¬ 
sion  accomplishment.  The  failure  or  loss  of  an  item  of  equipment  on  a  critical  task 
could  make  the  difference  between  mission  success  or  failure.  In  full  recognition 
of  the  [SIC]  fact,  it  is  easy  to  comprehend  the  emphasis  placed  on  life-cycle  sup¬ 
port.  It  is  also  easy  to  understand  why  military  personnel  and  civil  servants  resist 
change  in  the  methods  of  getting  or  planning  life-cycle  support.  Very  few  people 
are  willing  to  take  a  chance  to  specify  COTS/NDI  items  and  contractor  support 
because  of  the  fear  that  the  two  will  not  meet  mihtary  performance  and  support  re¬ 
quirements.”^ 


'  NSIA  “COTS/NDI”  Study,  p.  16 
^  Ibid.,  p.  17 


21-6 


The  study  further  states  that  existing  Army  regulations  reinforce  the  “business  as  usual”  mind-set, 
and  there  appears  to  be  no  differentiation  between  conventionally  developed  items  and  commer¬ 
cial  off-the-shelf  or  nondevelopmental  items.  It  concludes  the  discussion  of  Ufe-cycle  support  by 
calling  for  a  total  paradigm  shift  through  “an  innovative  environment  that  tolerates  and  promotes 
change  by  adding  enphasis  to  the  use  of  the  existing  commercial  support  system  and  pipeline  for 
life-cycle  support  of  COTS  items  of  equipment.”^  Additionally,  support  for  all  types  of  equipment 
must  be  ‘tailored”  to  each  item,  whether  it  is  developmental  or  nondevelopmental.  Regulation, 
publications,  and  training  should  be  developed  to  support  this  ‘tailored”  approach;  also,  there 
should  be  increased  dialogue  between  industry  and  Army  acquisition  personnel. 

In  June  1991,  the  Air  Force  Systems  Command  (AFSC)  and  the  Air  Force  Logistics  Command 
(AFLC)  published  a  Joint  study  called  the  “Joint  Command  Commercial  Off-The-Shelf  (COTS) 
Supportability  Working  Group  (CSWG)  Final  Report.”  Not  surprisingly,  the  CSWG  found  simi¬ 
lar  problems  with  supporting  NDI  in  the  Air  Force.  The  following  support  approach  issues  were 
outlined  in  the  Air  Force  report: 

“Commercial  items,  specifically  the  internal  configurations  of  commercial  items, 
change  with  the  market.  The  changes  are  driven  by  competitive  pressures.  The 
rhanging  market  allows  the  Air  Force  to  benefit  from  item  inqirovement  but  is  also  a 
major  source  of  many  of  the  supportability  problems  associated  with  CIs.  Over  time, 
the  support  problems  increase  as  spares,  software,  and  the  entire  support  base  evolve 
with  the  changing  item 

“Additionally,  Cl  acquisition  and  deployment  can  be  fast  paced.  Often  the  acquisi¬ 
tion  and  deployment  of  CIs  outstrip  the  Air  Force’s  ability  to  get  support  to  the 
field  on  time  and  keep  it  current  with  the  changing  commercial  configuration. 

“Support  for  changing,  fast  paced  commercial  acquisitions  is  complicated  by 
regulations  and  processes  that  are  geared  to  developmental  items  and  processes. 

The  Air  Force  attempts  to  fit  commercial  acquisitions  into  the  standard  support 
processes  for  areas  such  as  provisioning,  technical  orders,  common  support 
equipment,  and  engineering  data.”"* 

The  CSWG  study  discusses  acquisition  strategy  issues  contributing  to  inadequate,  up-front  sup¬ 
port  planning;  engineering  approaches  in  system  design  and  integration  that  impact  supportability, 
requirements  process  issues;  supply  support  issues;  and  “mind-set  issues. 

21.4  I.OGISTICS  CONSIDERATIONS  IN  THE  COMMERCIAL/NDI  ACQUISITION 
PROCESS 


In  response  to  increased  commercial/NDI  acquisition  and  recognizing  potential  problems  associ¬ 
ated  with  it,  the  Army  included  a  chapter  concerning  NDI  in  AMC/TRADOC  Pamphlet  70-2 
(Chapter  17).  The  chapter  provides  guidance  on  logistics  and  other  considerations  during  phases 


^  Ibid.,  p.  18 

AF  COTS  CSWG  Final  Report,  p.  5 
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of  an  NDI  acquisition.  It  provides  NDI-related  guidance  for  each  logistics  element.  The  follow¬ 
ing  paragraphs  examine  aspects  of  the  commercial/NDI  acquisition  process  as  discussed  in  the 
previously  mentioned  documents  and  other  studies  and  reports  on  the  subject. 

21.4.1  Market  Investigation/Market  Analysis 

During  market  investigation  conducted  by  the  acquiring  agency,  logistics  support  requirements 
information  should  be  provided  to  industry.  It  should  include  planned  maintenance  echelons, 
maintainer  proficiency  levels,  software  maintenance  plans,  limitations  on  evacuation  of  repair- 
ables,  maintenance  environment,  supply  support,  training  needs,  and  technical  data  needs.  In  their 
responses,  industry  should  provide  information  on  reliability  history,  maintainability  features, 
flexibility  for  government  maintenance  (licensing),  critical  interfaces  with  other  sub-systems  af¬ 
fecting  supportability,  maintenance  in  various  environments/conditions,  extent  of  competition  for 
support,  warranties,  current  military  and  commercial  customers,  estimated  life-cycle  costs,  and 
requirements/sources  of  logistics-related  training 

The  market  investigation  should  provide  sufficient  information  to  allow  supportability  to  be  thor¬ 
oughly  considered  in  the  subsequent  tradeoff  process.  However,  it  is  critical  in  this  stage  of  mar¬ 
ket  analysis  that  the  focus  remains  on  which  products  are  available  on  the  commercial  market  in¬ 
stead  of  which  technology  is  available.  Failure  to  do  this  could  result  in  available  technologies 
fi'om  different  products  being  consolidated  into  a  single  requirement,  making  utilization  of  the 
commercial  support  base  unpossible  or,  worse,  making  it  impossible  to  fulfill  the  requirement  all 
together.  Despite  the  focus  on  available  products,  thorough  examination  of  product  supportabil¬ 
ity  is  required. 

Selecting  a  commercial/NDI  solution  to  an  acquisition  does  not  imply  that  any  logistics  element 
can  be  ignored.  Commercial/NDI  candidates  must  be  thoroughly  assessed  during  the  market  in¬ 
vestigation  so  that  logistics  remains  a  critical  factor  in  the  decision  of  whether  a  commercial/NDI 
strategy  is  feasible.  In  arriving  at  logistics  decisions  regarding  commercial/NDI,  it  should  be  kept 
in  mind  that  the  commercial/NDI  alternatives  might  require  a  departure  from  traditional  methods 
of  acquiring  logistics  support.  Logistics  design  influence  (in  order  to  optimize  system  support- 
ability)  may  not  necessarily  work  for  an  already  designed  commercial/NDI  system.  It  is,  there¬ 
fore,  in^ortant  that  the  government  considers  what  has  been  accomplished  in  aU  the  logistics  ele¬ 
ments  to  assist  in  the  commercial/NDI  decision  and  identify  areas  requiring  more  effort. 

21.4.1  Coordination  with  “Test  Community” 

Concurrent  with  the  market  investigation  process,  the  program  office  prepares  the  Test  and 
Evaluation  Master  Plan  (TEMP)  in  cooperation  with  the  test  community.  It  is  important  to  en¬ 
sure  all  critical  logistics  support  related  requirements  are  identified  so  they  can  be  included  in  sub¬ 
sequent  testing.  Potential  sources  of  existing  data  relative  to  critical  logistics  support  related  re¬ 
quirements  should  be  identified.  Then,  these  requirements  must  be  coordinated  between  logistics 
personnel  representing  the  user  and  program  office  and  the  testing  community  for  inclusion  in  the 
TEMP. 
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21.4.2  Formulating  Support  Planning  and  Acquisition  Strategy 

At  this  point,  a  commercial/NDI  acquisition  strategy  will  be  developed  if  appropriate.  To  ensure 
logistics  considerations  are  incorporated  effectively  during  the  commercial/NDI  acquisition  proc¬ 
ess,  thorough  and  coordinated  planning  for  supportability  should  be  developed  m  conjunctmn 
with  developing  acquisition  strategy.  Planning  for  supportability  should  consider  all  logistics  ele¬ 
ments,  including  establishment  of  milestones  for  each  element.  With  a  commercial/NDI  acquisi¬ 
tion,  thoroughness  is  critical  in  this  stage  since  activities  related  to  both  Milestones  I  and  II  nor¬ 
mally  must  occur  during  this  phase.  Planning  for  deployment  and  postproduction  support  must 
accentuate  the  accelerated  nature  of  the  program  and  address  potential  problems  mvolved  with 
logistics  lagging  the  availability  of  a  commercial/NDI  system  from  the  production  line. 

As  one  respondent  said  in  an  NDI  survey,  ‘It  takes  me  18  to  20  months  to  do  a  user  and  market  survey 
and  put  on  contract  a  piece  of  commercial  equipment.  From  contract  award,  the  vendor  can  usually 
deUver  equipment  within  3  to  6  months;  it  takes  nearly  30  months  to  do  all  the  logistics  required  for 
fielding.  Logistics  is,  by  far,  the  ‘long  pole  in  the  tent’.  Technical  Manuals  (TMs)  and  Maintenance 
Aflocation  Charts  (MACs)  are  the  longest,  along  with  parts  provisioning  and  stocking.” 

During  the  logistics  planning  process,  analysis  should  be  made  regarding  the  utilization  of  the 
commercial/NDI  system  Decisions  on  how  the  commercial/NDI  system  will  be  supported  will 
result  from  this  analysis  process.  The  related  decisions  must  include  consideration  of  the  fact  that 
there  may  not  be  an  ideal  solution  to  support  this  item  Some  aspects  of  the  commercial/NDI 
support  will  be  less  than  optimal.  It  must  be  remembered  that  overall  benefits  of  acquiring  com- 
mercial/NDI  may  far  exceed  these  specific  logistics-related  concerns.  As  long  as  the  concerns  are 
recognized  and  support  planning  optimizes  the  risk  they  present,  effective  logistics  can  be 
achieved  for  the  life  of  the  commercial/NDI  system. 

As  the  logistics  planning  process  occurs,  support  decisions  are  incorporated  into  the  overall  ac¬ 
quisition  strategy.  The  issue  of  contractor  versus  organic  support  is  a  critical  decision. 

There  are  five  system-use  factors: 

•  How  will  the  commercial/NDI  be  used,  i.e.,  from  “as  is”  to  fully  militarized  modification? 

•  Where  will  the  commercial/NDI  be  used,  i.e.,  in  what  environment  -  from  a  fixed/ 
industrial/no n-hostile  one  to  a  mobile/austere/hostile  one? 

•  What  is  the  projected  service  life? 

•  When  is  the  commercial/NDI  to  be  used,  i.e. ,  to  be  deployed  immediately  or  sometime  in 
the  future? 

•  Why  is  a  commercial/NDI  being  selected;  i.e.,  it  is  taking  advantage  of  an  advancing  tech¬ 
nology  (with  changing  configurations)  or  the  availability  of  a  proven,  stable  design? 
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Each  use  factor  shows  a  range  of  support  methods.  These  methods  range  from  no  support,  which 
unplies  disposal  upon  failure,  to  full  organic  support.  The  methods  also  include  full  contractor 
support  and  combined  contractor/organic  support. 

It  should  be  emphasized  that  the  utilization  of  these  five  system-use  factors  in  the  manner  de¬ 
scribed  in  Figure  21-1  is  flexible.  For  exanple,  even  though  a  commercial/NDI  system  may  be 
deployed  in  the  future  and  will  have  a  prolonged  service  life,  contractor  support  may  be  desirable. 
The  bottom  line  is  that  utilization  of  these  factors  assists  in  considering  a  support  approach  and 
does  not  represent  a  rigid  method  for  decision  making. 


CONTRACTOR  VERSUS  ORGANIC  SUPPORT 
CONSIDERATIONS  WITH  NDI 


HOW 


As  is 


Militarized 


WHERE  (ENVIRONMENT) 


Rxed/Industrial/Non-Hostile 


Mobile/Austere/Hostile 


Limited  Time 


immediately 


HOW  LONG 

Prolonged  Period 

WHEN 

Future 


WHY 


Technologically  Advancing  Stable  Design 


SUPPORT  METHOD: 

No  Organic 

Mostly  Contractor 

Mostly  Organic 

All  Organic 

Support 

Support 

Support 

Support 

Figure  21-1.  Contractor  v.  Organic  Support 
21.4.3  Need  for  Policy  Changes 

In  the  Air  Force  “Joint  Command  Commercial  Off-the-Shelf  (COTS)  Supportability  Working 
Group  (CSWG)  Final  Report,”  the  CSWG  recommended  the  foUowing: 

‘Policy  changes:  Contractor  support  is  preferred  for  commercial  acquisitions  un¬ 
less  mission  needs  are  not  met.  Because  the  vendor  manages  and  controls  the  in¬ 
ternal  configuration  of  the  commercial  item,  which  is  continually  changing  to  meet 
the  demands  of  the  competitive  marketplace,  contractor  support  is  the  approach 
that  best  allows  the  Air  Force  to  support  this  item.  Contractor  support  permits 
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configuration  changes  without  the  changes  in^acting  the  end-user,  and  without  the 
requirement  for  a  continued  update  of  a  military  orgamc  support  system.  In  addi¬ 
tion,  whether  it  is  a  vendor  or  third  party  that  provides  the  support,  the  Air  Force 
should  accept  commercial  support  because  it  is  often  readily  available,  has  a 
proven  track  record,  and  is  competitively  priced.  Contractor  provided  data,  in¬ 
cluding  data  on  equipment  usage  and  operation,  general  maintenance  tips,  recom¬ 
mended  spares,  etc.,  should  be  accepted  in  contractor  format.  Special  provisions 
to  procure  military  specification,  government  formatted  data  should  be  avoided. 

“When  operational  requirements  dictate  an  organic  support  approach,  the  Air 
Force  should  evaluate  the  requirements  for  technical  data  on  a  case-by-case  basis. 
Commercial  item  documentation  should  be  limited  to  data  that  permits  the  Air 
Force  to  perform  minor  maintenance  on  and  to  operate  the  commercial  item. 

Source  control,  specification  control,  and  interface  control  drawings  are  recom¬ 
mended  for  inclusion  in  the  technical  data  package  for  commercial  items  integrated 
into  a  system. 

‘The  second  policy  change  should  state  that  vendor  support  concepts  should  be 
applied  whether  the  support  is  organic  or  contract.  The  Air  Force  should  not  cre¬ 
ate  a  support  approach  that  varies  from  the  commercial  mainstream  for  that  item. 

For  example,  the  Air  Force  should  not  remove  and  replace  circuit  cards  when  the 
vendor  concept  is  to  remove  and  replace  black  boxes.  The  Air  Force  should  not 
perform  field  level  repair  of  circuit  cards  when  the  vendor  repairs  cards  at  the  de¬ 
pot  level.  Before  the  commercial  item  support  concept  is  selected  or  changed,  a 
thorough  life-cycle  cost  and  effectiveness  analysis  should  be  done  and  aU  affected 
commands  coordinate  on  the  decision. 

“Finally,  the  Air  Force  should  select  the  vendor  support  approach  that  meets  its 
needs.  (Note:  The  apparent  conflict  with  the  previous  paragraph  is  recognized; 
however,  it  was  not  changed  to  maintain  the  integrity  of  the  quote.)  If  the  vendor 
has  options  for  support,  or  different  approaches,  the  Air  Force  should  select  the 
approach  that  best  meets  its  needs.  These  policies  require  the  Air  Force  to  define 
the  support  concept  early,  specify  it,  and  select  vendors  whose  support  approaches 
meet  Air  Force  needs  without  modification.”^ 

21.4.4  Official  Recognition  of  Benefits 

Potential  benefits  of  contractor  support  were  recognized  by  DoD  and  are  included  in  the  latest 

versions  of  DoD  5000. 1  and  DoD  5000.2-R: 

“3.3.7  Source  of  Support:  It  is  DoD  policy  to  retain  limited  organic  core  depot 
maintenance  capability  to  meet  essential  wartime  surge  demands,  promote  compe¬ 
tition,  and  sustain  institutional  expertise.  Support  concepts  for  new  and  modified 


*  Ibid.,  p.  6-7 
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systems  shall  maximize  the  use  of  contraetor-provided,  long-term,  total  life-cycle 
logistics  support  that  combines  depot-level  maintenance  along  with  wholesale  and 
selected  retail  materiel  management  functions.  Life-cycle  costs  and  use  of  existing 
capabilities,  particularly  while  the  system  is  in  production,  shall  play  a  key  role  in 
the  overall  selection  process.  Other  than  stated  above,  and  with  an  appropriate 
waiver,  DoD  organizations  may  be  used  as  substitutes  for  contractor-provided  lo¬ 
gistics  support,  such  as  when  contractors  are  unwilling  to  perform  support,  or 
where  there  is  a  clear,  well-documented  cost  advantage.  The  PM  shall  provide  for 
long-term  access  to  data  required  for  competitive  sourcing  of  systems  support. 

The  waiver  to  use  DoD  organizations  must  be  approved  by  the  MDA.” 

Utilizing  supportabdity  analysis  is  beneficial  during  the  market  investigation,  drafting  of  require¬ 
ments  documentation,  and  the  logistics  planning  process.  Its  use  can  focus  on  potential  problems 
and  lead  to  sound  solutions.  It  defends  development  of  logistics  support  concepts.  DoD  5000.2R 
delineates  the  following  criteria  for  supportability: 


...analyses  shall  be  conducted  as  an  integral  part  of  the  systems  engineering  proc¬ 
ess  beginning  at  program  initiation  and  continuing  throughout  program  develop¬ 
ment.  Supportability  analyses  shall  form  the  basis  for  related  design  requirements 
included  in  the  system  speeification  and  for  subsequent  deeisions  concerning  how 
to  most  cost-effectively  support  the  system  over  its  entire  life  cycle.  Programs 
shall  allow  eontractors  the  maximum  flexibility  in  proposing  the  most  appropriate 
supportability  analyses. 

“Acquisition  programs  shall  establish  logistics  support  concepts  (e.g.,  two  level, 
three  level)  early  in  the  program  and  refine  them  throughout  the  development  pro¬ 
cess.  Life-cycle  costs  shall  play  a  key  role  in  the  overall  selection  process.  Sup¬ 
port  eoncepts  for  new  and  future  weapon  systems  shall  provide  for  cost  effective 
total  life-cycle  logistics  support.” 

Figure  21-2  depicts  the  supportability  analysis  process  for  commercial/NDI  systems. 
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Figure  21-2;  Commercial/NDI  Supportability  Analysis  Flow  Diagram 


21.5  COMMERCTAL/NDI  CONSIDERATIONS  FOR  SELECTED  LOGISTICS 
ELEMENTS 


To  comprehend  folly  the  logistics  issues  related  to  commercial/NDI  acquisition,  it  is  beneficial  to 
examine  several  logistics  elements  and  the  commercial/NDI  considerations  relative  to  each. 

21.5.1  Technical  Data 

A  problem  associated  with  the  acquisition  of  technical  data  relative  to  a  commercial/NDI  acquisition  is 
one  of  data  rights.  ‘Data  rights”  refer  to  the  authority  to  use,  duplicate,  or  disclose  data.  The  govern¬ 
ment  acquires  data  rights  to  develop  specifications,  to  increase  competition  and  to  foster  technological 
development.  Industry  perceives  that  the  release  of  data  to  conpetitors  will  erode  their  competitive 
edge  and  has  cited  this  as  a  major  impediment  for  doing  business  with  the  government. 


Because  data  rights  are  considered  “proprietary,”  commercial  firms  are  reluctant  to  disclose  tech¬ 
nical  or  other  data  to  customers.  Commercial  contracts  do  not  request  this  kind  of  data  because  it 
is  not  a  sound  business  practice.  DoD  buyers  should  consider  depending  more  heavily  on  alterna¬ 
tives  such  as  warranties  and  training,  which  is  a  practice  their  commercial  counterparts  engage  in 
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when  they  resort  to  acquiring  data  rights  as  a  last  option.  If  necessary,  licensing  is  available  as  an 
alternative  to  purchasing  technical  data,  e.g.,  exclusive,  semi-exclusive,  or  nonexclusive  licenses.® 

Only  the  minimum  data  needed  to  permit  cost-effective  support  of  research,  development,  pro¬ 
duction,  cataloging,  provisioning,  training,  operation,  maintenance,  and  related  logistics  functions 
over  the  life  cycle  of  the  item  should  be  acquired.  Preference  should  be  given  to  contractor  format 
data  and  maximum  use  of  commercial  technical  manuals. 

Another  option,  data  rights  escrow,  involves  an  agreement  to  deliver  a  detailed  technical  data 
package  at  a  later  date,  normally  when  production  is  nearing  completion  or  when  the  information 
no  longer  represents  a  competitive  advantage  for  the  manufacturer.  This  is  useful  primarily  when 
DoD  win  be  maintaining  an  older  model  than  that  carried  in  the  commercial  marketplace. 

Relative  to  technical  data,  the  bottom  line  is  that  the  government  must  establish  its  initial  support 
requirements  data  necessary  to  fulfiU  those  requirements;  determine  sources  of  the  commer- 
cial/NDI  wining  or  capable  of  providing  required  data;  and  perform  any  tradeoff  analysis  required. 
The  government  must  then  adjust  or  confirm  support  strategy  relative  to  acquisition  strategy;  ad¬ 
just  data  requirements,  if  necessary;  and  procure  the  data.  Implementing  a  thorough,  coordinated, 
iterative  process,  based  on  detafied  planning,  ensures  that  this  acquired  technical  data  results  in  an 
efiectively  supported  commercial/NDI. 

21.5.2  Maintenance  Planning 

The  exchange  of  information  between  government  and  industry  in  the  market  investigation/market 
analysis  process,  with  consideration  of  various  factors  such  as  density,  environment,  availability 
and  format  of  technical  data,  warranties,  etc.,  provides  for  the  iterative  generation  of  a  maintenance 
concept  as  part  of  the  support  strategy.  The  resultant  decision  to  use  organic  support,  contractor  sup¬ 
port,  or  a  mix  as  an  interim  or  long-term  measure  is  a  product  of  the  tradeoff  process. 

Preference  for  contractor  support  of  commercial/NDI  is  taking  hold  throughout  DoD.  Confi¬ 
dence  in  this  approach  grew  substantially,  based  upon  many  cases  of  successful  contractor  sup¬ 
port  during  Operation  Desert  Storm.  Dialogue  with  industry,  which  determines  what  is  necessary 
and  uses  an  iterative  process  of  tradeoff  analysis  considering  all  pertinent  factors,  can  produce 
positive  results. 

21.5.2  Supply  Support 

The  decision  on  which  level  repairs  will  be  performed  and  who  wiU  perform  them  (contractor,  or¬ 
ganic,  mix)  will  have  a  direct  impact  on  spares/repair  parts  requirements.  Availability  of  technical 
data  for  reprocurement/spares  breakout  will  influence  sources  of  supply  support.  The  “business- 
as-usual”  tendency  is  to  buy  Level  III  drawings  and  documentation  to  the  piece-part  level.  This 
procedure  is  often  expensive  and  may  lead  to  procurement  of  poor-quality  parts.  More  impor- 


*  DSMC,  Commercial  Practices  for  Defense  Acquisition  Guidebook,  p.  9-6 
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tantly,  the  government’s  insistence  on  having  such  detailed  techmcal  data  may  cause  potential  of¬ 
ferors  of  highly  desirable  commercial/NDls  to  refuse  to  offer  their  product. 

Effective  supply  support  is  possible  with  a  commercial/NDI.  The  LAV-25  program  utilized  the 
contractor’s  Recommended  Buy  List  (RBL),  which  recommended  quantities  of  spares  and  repair 
parts  sufficient  to  support  the  LAV-25  during  the  first  12  months  of  initial  fielding.  An  approach 
such  as  this  is  consistent  with  Spares  Acquisition  Integrated  with  Production  (SAIP).  T^s  ap¬ 
proach,  combined  with  interim  contractor  supply  support,  will  ensure  supportability  while  the 
screening  and  cataloging  activities  of  the  provisioning  process  are  taking  place. 

Concern  has  been  expressed  about  buying  NDIs  because  the  manufacturer  may  discontinue  pro¬ 
duction  and  support  of  the  equipment  while  the  item  is  still  used  by  DoD.  Potential  problems  of 
this  nature  should  be  discussed  with  potential  offerors  early  in  the  commercial/NDI  acquisition 
process.  If  the  possibility  exists  that  production  and  support  might  cease  before  a  time  desirable 
by  the  government,  several  options  exist; 

•  The  Government  may  want  to  buy  upgrades  as  commercial  models  evolve.  This  is 
sometimes  done  in  unstable  technology  areas,  such  as  con^uter  hardware  and  software. 

•  Another  alternative  is  a  onetime  purchase  of  spares.  This  purchase  could  be  made 
when  the  end-item  is  procured  or  through  an  agreement  requiring  timely  government 
notification  so  spares  can  be  purchased. 

•  Finally,  arrangements  can  be  made  to  obtain  technical  data  sufficient  to  solicit  sources 
of  supply  support  concurrent  with  the  end  of  the  manufacturer  s  production^support. 
This  concept,  called  data  rights  escrow,  is  often  more  palatable  to  manufacturers  than 
providing  Level  III  tech  data  up  fi-ont  because  it  does  not  result  in  loss  of  any  com¬ 
petitive  advantage.  The  competitive  advantage  remains  because  the  tech  data  is  trans¬ 
ferred  at  a  time  when  the  NDI  is  no  longer  a  competitive  product  for  the  manufacturer. 

21.6  CONCLUSION 

One  of  the  toughest  challenges  in  commercial/NDI  acquisition  is  ensuring  effective  logistics.  Ac¬ 
quisition  lead  time  is  reduced,  leaving  less  time  to  do  the  planning  for,  and  development  of,  or¬ 
ganic  support.  However,  commercial/NDI  may  have  support  in  place  since,  in  many  cases,  the 
item  is  being  used,  broken,  and  fixed.  Therefore,  a  support  structure,  training,  and  reliability  data 
may  already  exist. 

Potential  supportability  problems  must  be  addressed  early  in  the  commercial/NDI  acquisition  pro¬ 
cess.  As  part  of  the  market  investigation,  logistics  support  requirements  must  be  provided  to  in¬ 
dustry.  Their  feedback  will  provide  the  information  necessary  to  facilitate  the  subsequent  tradeoff 
decisions  that  must  take  place. 

21.7  REFERENCE 

“Buying  Commercial  &  Nondevelopmental  Items:  A  Handbook,”  April  1996.  Available  in  the 
DoD  Acquisition  Deskbook. 
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22 

JOINT  PROGRAM  LOGISTICS 

. .  it  is  not  always  possible  to  have  everything  go  exactly 
as  one  likes.  In  working  with  Allies  it  sometimes  happens 
that  they  develop  opinions  of  their  own.  ” 

Winston  Churchill, 

The  Second  World  War  (1950) 


22.1  POD  POLICY 

The  Office  of  the  Secretary  of  Defense  (OSD)  and  Congress  encourage  Joint  programs. 

These  programs  provide  opportunities  to  reduce  acquisition  and  logistic  support  costs  and  to 

improve  interoperability  of  equipment  in  Joint  operations. 

DoD  5000.2-R  states  that: 

“Any  acquisition  system,  subsystem,  component,  or  technology  program 
that  involves  a  strategy  that  includes  funding  by  more  than  one  DoD 
Component  during  any  phase  of  a  system's  life  cycle  shall  be  defined  as  a 
joint  program.  Joint  programs  shall  be  consolidated  and  collocated  at  the 
location  of  the  lead  Component's  program  office,  to  the  maximum  extent 
practicable.  This  includes  systems  where  one  DoD  Component  may  be 
acting  as  acquisition  agent  for  another  DoD  Component  by  mutual  agree¬ 
ment  or  where  statute,  DoD  Directive,  or  the  USD  (A&T)  or  ASD  (C  I) 
has  designated  a  DoD  organization  to  act  as  the  lead  (e.g.,  USSOCOM, 

BMDO,  DARO).  In  the  case  of  a  designated  organization  given  acquisi¬ 
tion  responsibihties,  the  CAE  of  that  organization  shall  utihze  the  acquisi¬ 
tion  and  test  organizations  and  facilities  of  the  Military  Departments  to  the 
maximum  extent  practicable,  rather  than  create  new,  unique  organizations 
and  facilities.  The  relationship  between  the  designated  organization  and 
the  Military  Departments  and  Defense  Agencies  shall  be  specified  in  a 
Memorandum  of  Agreement  (MO A).  Mission  needs,  operational  re¬ 
quirements,  and  program  strategies  shall  be  structured  to  encourage  and  to 
provide  an  opportunity  for  multi-Component  participation.  The  DoD 
Components  shall  periodically  review  their  programs  and  requirements  to 
determine  the  potential  for  cooperation. 

“The  JROC,  or  Principal  Staff  Assistant  (PSA)  for  ACAT  lA  programs, 
shall  review  and  validate  ACAT  I  or  ACAT  lA  Component  MNS  and 
ORDs,  as  appropriate,  and  shall  recommend  estabhshment  of  joint 
programs  based  on  their  joint  potential.  DoD  Component  Heads  shall  also 
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recommend  establishment  of  joint  programs.  The  decision  to  establish  a 
joint  program  shall  be  made  by  the  MDA,  who  shall  designate  the  lead 
Component  as  early  in  the  acquisition  process  as  possible.  The  decision  to 
establish  a  joint  program  shall  be  based  on  the  recommendation  of  the 
JROC  for  programs  that  shall  be  reviewed  by  the  Defense  Acquisition 
Board  (DAB),  the  recommendation  of  the  functional  PSA  and  Assistant 
Secretary  of  Defense  for  Command,  Control  and  Communications  (ASD 
(C3I))  for  programs  that  shall  be  reviewed  by  the  Major  Automated  In¬ 
formation  Systems  Review  Council  (MAISRC),  or  the  reconunendation  of 
the  DoD  Component  Head  (or  a  designated  representative)  for  all  other 
programs. 

“The  designated  lead  DoD  Component  Head  shall  select  a  single  qualified 
program  manager  for  the  designated  joint  program.  The  selected  joint 
program  manager  is  fully  responsible  and  accountable  for  the  cost,  sched¬ 
ule,  and  performance  of  the  system  development.  In  cases  where  the  joint 
program  is  a  consolidation  of  several  programs  with  multiple  Component 
program  managers,  the  joint  program  manager  retains  responsibility  for 
overall  system  development  and  integration. 

“A  designated  joint  program  shall  have  one  quality  assurance  program, 
one  program  change  control  program,  one  integrated  test  program,  and  one 
set  of  documentation  and  reports  to  include  one  Joint  ORD,  one  Test  and 
Evaluation  Master  Plan  (TEMP),  one  APB,  one  DAES,  one  Quarterly  Re¬ 
port  for  ACAT  LA  programs,  and  one  Selected  Acquisition  Report  (SAR) 
for  ACAT  I  programs.  The  documentation  for  milestone  reviews  and  pe¬ 
riodic  reports  shall  flow  only  through  the  lead  DoD  Component  acquisi¬ 
tion  chain,  and  shall  be  supported  by  the  participating  DoD  Components. 
Unless  otherwise  directed  by  the  MDA  or  agreed  to  through  an  Memoran¬ 
dum  of  Agreement  (MO A)  signed  by  all  Components,  the  lead  DoD  Com¬ 
ponent  shall  budget  for  and  manage  the  common  RDT&E  funds  for  as¬ 
signed  joint  programs.  Individual  DoD  Components  shall  budget  for  then- 
unique  requirements.  Inter-Component  logistics  support  shall  be  utilized 
to  the  maximum  extent  practicable,  consistent  with  effective  support  to  the 
operational  forces  and  efficient  use  of  DoD  resources. 

“A  lead  organization  shall  be  designated  to  coordinate  all  operational  test 
and  evaluation  involving  more  than  one  DoD  Component.  A  single  report 
on  operational  effectiveness  and  suitabihty  will  be  produced. 

“DoD  Components  may  not  terminate  or  substantially  reduce  participation 
in  joint  ACAT  LD  programs  without  the  approval  of  the  USD  (A&T).  Be¬ 
fore  any  such  termination  or  substantial  reduction  is  approved,  the  pro¬ 
posed  termination  or  substantial  reduction  shall  be  reviewed  by  the  JROC. 
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‘The  USD  (A&T)  may  require  a  Component  to  continue  to  provide  some 
or  all  of  the  funding  necessary  to  allow  the  joint  program  to  continue  in  an 
efficient  manner  after  approval  of  a  Component  request  to  terminate  or 
substantially  reduce  that  Component's  participation  (10  USC  §231  l(c)29). 
Substantial  reduction  is  defined  as  a  funding  or  quantity  decrease  of  50% 
or  more  in  the  total  funding  or  quantities  in  the  latest  President's  Budget 
for  that  portion  of  the  joint  program  funded  by  the  Component  seeking  to 
reduce  its  participation.” 

22.2  LOGISTICS  SUPPORT 

Logistics  management  of  joint  programs  is  similar  to  that  of  single  Service  programs,  with 
one  major  exception  —  joint  program  management  requires  the  accommodation  of  each 
participating  Service's  unique  requirements  resulting  fi'om  differences  in  equipment  de¬ 
ployment,  mode  of  employment,  and  support  concepts. 

In  Joint  programs,  logistics  is  often  the  most  serious  planning  constraint.  It  is  important  to 
understand  the  logistics  policies  and  procedures  of  both  the  lead  Component  and  the  par¬ 
ticipating  Component  to  field  a  sustainable  system  successfully.  Continuous  Acquisition 
and  Life-Cycle  Support  (CALS)  should  be  considered  for  integration  into  Joint  programs. 
Failure  to  achieve  logistics  agreements  with  Component  logistics  chiefs  can  lead  to  man¬ 
datory  reviews  and  program  turbulence.  Logistics  support  plans  may  be  prepared  to 
document  the  required  logistics  support  if  desired  by  the  PM  or  as  advised  by  the  IPTs. 

22.3  LOGISTICS  OBJECTIVES 

Logistics  management  objectives  of  joint  programs  are  to: 

•  realize  economies  by  Joint  performance  of  logistics  planning,  analysis,  and  docu¬ 
mentation; 

•  satisfy  essential  logistic  support  needs  of  each  Service;  and 

•  effectively  attain  established  readiness  and  supportabUity  objectives. 

22.4  MANAGEMENT  ISSUES 

There  is  no  overall  single  structure  for  the  management  of  Joint  programs.  The  military 
services  should  seek  to  build  a  structure  that  responds  rapidly  to  decisions  of  the  lead 
Service  PM  and  LM  and  provides  a  direct  information  path  conveying  the  requirements  of 
each  mihtary  service  to  the  PM.  Typical  staffing  of  a  Joint  program  office  includes  the 
following  considerations: 

•  The  lead  Service  typically  establishes  a  staffing  document  for  the  program  office; 
representatives  of  the  participating  Services  fill  the  positions.  The  staffing  docu- 
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ment  also  designates  key  positions  for  the  senior  representative  of  each  participat¬ 
ing  Service. 

•  The  participating  Services  normally  assign  personnel  to  fill  identified  positions  in 
the  jointly  staffed  program  office.  The  senior  representative  assigned  to  the  pro¬ 
gram  office  reports  directly  to,  or  has  direct  access  to,  the  PM  and  also  functions 
as  the  participating  Service's  representative  on  all  issues  pertaining  to  that  Service. 

•  The  lead-Service  PM  usually  establishes  an  IPT,  which  includes  members  from  the 
lead  and  participating  Services.  The  purpose  of  the  IPT  is  to  accomplishment  all 
logistics  functions,  including  the  performance  of  aU  logistic  support  analysis  for  the 
Joint  program. 

•  Each  participating  Service  normally  designates  a  PM  to  support  the  lead-Service 
PM. 

22.5  DOCUMENTATION  OF  JOINT  PROGRAMS 

Initial  program  documentation,  beginning  with  the  Mission  Need  Statement  (MNS),  is 
customarily  prepared  by  the  Service  that  first  identifies  a  mission  deficiency  that  cannot  be 
satisfied  by  a  non-material  solution.  The  MNS  is  prepared  prior  to  establishment  of  a  pro¬ 
gram.  It  is  forwarded  for  validation  of  the  need  and  consideration  of  Joint  potential  to  the 
Service's  operational  validation  authority  or,  for  programs  with  potential  to  become  major 
defense  programs,  to  the  Joint  Requirements  Oversight  Council  (JROC).  Joint  potential 
should  be  considered  during  MNS  development  including  the  identification  of  needs  that 
may  cross  Service  boundaries  and  coordination  with  the  Services  affected  concerning  the 
potential  for  a  Joint  program.  Significant  logistics  constraints  should  be  clearly  identified 
in  the  MNS. 

The  MNS  will  be  further  considered  by  the  Milestone  Decision  Authority  (MDA)  at  Mile¬ 
stone  0  to  determine  if  it  justifies  further  effort.  If  so,  a  studies  phase  will  be  initiated  to 
identify  and  evaluate  alternatives  to  meet  the  deficiency.  Normally,  an  acquisition  pro¬ 
gram,  per  se,  will  not  yet  exist.  The  Service  imtiating  the  MNS  will  bear  responsibility  for 
developing  appropriate  documentation  for  the  program  initiation  decision  at  Milestone  I. 
Some  level  of  support  would  normally  be  provided  by  the  other  Services  if  the  program 
has  been  identified  as  one  with  Joint  potential.  Full  consideration  of  other  Service  re¬ 
quirements,  operational  concepts,  and  logistics  support  systems  is  crucial  during  this  study 
phase.  Many  of  the  basic  logistics  system  design  decisions  are  made  here. 

Once  a  joint  program  is  formally  established  at  MS  I,  a  lead  Service  (normally,  but  not  al¬ 
ways,  the  Service  that  initiated  the  MNS)  will  be  designated.  From  that  point  forward,  the 
lead  Service  has  primary  responsibility  for  aU  program  documentation.  Joint  program  ’ 
milestone  documents  are  single  documents  with  separate  appendices,  when  required,  to 
support  Service-peculiar  requirements. 


22-4 


2.6  LOGISTICS  FUNDING  FOR  JOINT  PROGRAMS 


Each  participating  Service  uses  its  own  Service  channels  to  identify  program  requirements 
to  OSD.  However,  the  Joint  PM  maintains  overall  responsibility  for  identification  of  total 
funding  requirements  and  their  inclusion  in  a  Joint  Program  Funding  Plan.  The  Joint  PM 
also  consolidates  contracting  requirements  and  contract  awards  for  the  entire  development 
and  production  program.  The  participating  Services  transfer  the  required  obligational 
authority  to  the  Joint  Program  Office  or  that  office's  supporting  command  for  this  pur¬ 
pose. 

22.7  UNIQUE  LOGISTICS  REQUIREMENTS 

As  previously  stated,  the  Services  will  often  operate  the  systems  with  differing  operating 
profiles,  supply,  maintenance  support  concepts,  and  unique  support  equipment.  Tech¬ 
niques  to  accommodate  essential  Service  —  unique  requirements  within  the  framework  of 
common  approaches  are  discussed  in  the  subsections  below. 

22.7.1  Support  Analyses 

Logistics  Managers  (LMs)  of  a  Joint-Service  Program  should  endeavor  to  reach  agree¬ 
ment  on  corrunon  models  for  each  analytic  technique  applied  to  the  Joint  system.  Use  of 
common  models  will  reduce  the  total  analytical  effort  and  also  reduce  differences  in  the 
results  obtained.  Some  differences  will  remain  due  to  Service  variations  in  logistic  pa¬ 
rameters,  e.g.,  order  and  ship  time,  and  maintenance  concepts. 

22.7.2  Technical  Publications 

The  Services  have  different  requirements  for  technical  publications,  manuals,  and  orders. 

In  addition  to  the  variations  in  support  concept,  operational  role,  and  configuration  men¬ 
tioned  in  the  previous  paragraph,  there  could  also  be  differences  in  the  reading  compre¬ 
hension  levels  of  the  target  audience.  The  Services  generally  have  been  successful  in  ac¬ 
commodating  those  differences  in  Joint-use  technical  orders  and  technical  manuals,  espe¬ 
cially  when  the  Joint  approach  begins  at  program  initiation.  Reading  comprehension  levels 
occupy  a  range  rather  than  a  precise  point  value;  the  Services  seek  a  single  target  level 
that  satisfies  the  needs  of  each  Service.  Other  differences  are  covered  in  the  body  of  the 
specific  publication  or  in  Service  supplements. 

22.7.3  Training 

Training  requirements  vary.  The  Services  employ  different  skill  specialty  code  systems  as 
well  as  different  maintenance  concepts.  Single  location  traming  for  a  Jointly  used  system 
can  still  be  cost-effective  and  should  be  considered  early  in  the  planning  cycle.  As  one  ex¬ 
ample,  Air  Force  and  Army  personnel  receive  common  maintenance  training  on  the  TSC 
94  and  TSC  100  satellite  terminals  at  the  Army's  Ft.  Gordon  training  facility. 
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22.1  A  Depot  Maintenance  Interservicing  (DMI) 


DMI  studies  seek  to  avoid  unnecessary  duplication  of  facilities  and  equipment  among  the 
Services.  The  studies  have  been  performed  effectively  for  both  single  Service  and  multi- 
Service  new  starts.  Interservicing  plans  for  Joint  programs  should  be  addressed  in  the 
Joint  logistics  plan.  This  approach  has  been  applied  very  effectively  on  Joint  programs. 
The  TRI-TAC  Program  develops  tactical  communications  systems  used  by  the  Army, 
Navy,  Air  Force,  and  Marine  Corps.  The  PM  has  identified  TRI-TAC  items  to  be  man¬ 
aged  by  individual  Services.  The  designated  Service  then  provides  depot  support  for  all 
users  of  that  system. 

22.8  SUMMARY 

•  Joint  implementation  of  logistics  planning,  analyses,  and  documentation  can  reduce 
total  logistics  support  costs  and  meet  essential  needs  of  each  Service. 

•  As  with  Single-Service  programs,  effective  Joint  logistics  programs  require  early 
planning  starting  prior  to  Milestone  0  and  continuing  during  the  Concept  Explora¬ 
tion  phase  and  beyond. 

•  Jointly  staffed  program  offices  and  effective  inter-Service  communication  have 
been  major  contributors  to  the  success  of  Joint  program  management. 
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23 

INTERNATIONAL 
PROGRAM  LOGISTICS 


Give  us  the  tools,  and  we  will  finish  the  job. 

Winston  Churchill 
BBC  broadcast,  February  9,  1941. 


23.1  INTERNATIONAL  PROGRAMS  SCOPE 

This  chapter  provides  a  brief  overview  of  the  major  logistic  aspects  of  international  pro¬ 
grams.  For  purposes  of  this  guide,  international  programs  wiU  be  limited  to  certain  activi¬ 
ties  that  broadly  fit  within  the  categories  Usted  below.  Some  overlapping  exists  in  these 
categories  depending  on  organizational  view  or  perspective  of  a  given  international  pro¬ 
gram,  i.e.,  congressional  oversight  view,  program  administrative  responsibilities  within 
DoD,  year-to-year  wording  within  federal  law,  funding  legislation,  etc.  The  categories 
are: 

•  security  assistance, 

•  international  armaments  cooperation, 

•  Joint  Military  arrangements  and  operations  with  allied  nations,  and 

•  direct  commercial  sales. 

23.2  SHORT  DEFINITIONS  OF  INTERNATIONAL  PROGRAMS 

•  International  louistics  is  the  planning,  negotiating,  and  implementation  of  sup¬ 
porting  logistics  arrangements  between  nations,  their  forces,  and  agencies.  It  in¬ 
cludes  furnishing  logistics  support  (major  end  items  ...)  to,  or  receiving  logistics 
support  from,  one  or  more  friendly  foreign  governments  ...  with  or  without  re¬ 
imbursement.  It  also  includes  planning  and  actions  related  to  the  intermeshing 
of ...  forces  on  a  temporary  or  permanent  basis.  International  logistics  involves 
planning  ...  to  meet  requirements  of...  forces.  (See  Reference  1  at  Section  23.5.) 

•  Security  assistance  is  a  group  of  programs  authorized  by  the  Foreign  Assistance 
Act  of  1961,  as  amended,  and  the  Arms  Export  Control  Act  (AECA),  as 
amended,  or  other  related  statutes  by  which  the  United  States  provides  defense 
articles,  military  training,  and  other  defense-related  services  by  grant,  credit,  cash 
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sale,  lease,  or  loan,  in  furtherance  of  national  policies  and  objectives.  (See  Ref¬ 
erence  1  at  Section  23.5.) 

•  International  armaments  cooperation  describes  DoD  efforts  focused  on  interna¬ 
tional  cooperative  research,  development,  test  and  evaluation;  joint  production 
resulting  from  cooperative  R&D  programs;  DoD  procurement  of  foreign  equip¬ 
ment  technology  or  logistic  support;  and,  testing  of  foreign  equipment.  (See 
Reference  2  at  Section  23.5.) 

•  Joint  Military  arrangements  and  operations  with  allied  nations:  Logistic  “trans¬ 
fers”  that  come  into  play  during  combined  exercises,  training,  deployments,  op¬ 
erations  or  other  unforeseen  contingencies.  Transfers  are  exercised  by  unified 
and  Component  commanders  under  the  authority  of  acquisition  and  cross  serv¬ 
icing  agreements  (North  Atlantic  Treaty  Organization  Mutual  support  Act  of 
1979,  as  amended).  This  subject  is  addressed  in  Section  23.3.3.1,  below.  (See 
Reference  2  at  Section  23.5.) 

•  Direct  commercial  sales:  A  sale  of  defense  articles  or  defense  services  made  un¬ 
der  a  Department  of  State-issued  license  by  U.S.  industry  directly  to  foreign 
buyer,  and  which  is  not  administered  by  DoD  through  Foreign  Military  Sales 
(FMS)  procedures.  This  subject  is  addressed  in  Section  23.4.3.2,  below.  (See 
Reference  1  at  Section  23.5.) 

23.3  COOPERATIVE  LOGISTICS 

23.3.1  Introduction 

Cooperative  Logistics  refers  to  any  cooperation  between  the  U.S.  and  allied  or  friendly 
nations  or  international  organizations  in  the  logistical  support  of  defense  systems  and 
equipment  used  by  the  cooperating  Armed  Forces.  Cooperative  logistics  is  a  logical  ex¬ 
tension  of  the  acquisition  process,  but  being  also  a  substantial  part  of  military  operations, 
much  of  the  implementation  process  involves  security  assistance  and  FMS  processes  and 
procedures.  Even  though  some  of  the  processes  described  in  this  section,  are  under  the 
cognizance  of  the  Defense  Security  Assistance  Agency  (DSAA),  they  are  included  here  for 
completeness  and  will  be  noted  again  in  Section  23.4,  Security  Assistance. 

Cooperative  logistics  support  includes: 

•  Logistics  Cooperation  International  Agreements  (lAs),  used  to  improve  sharing 
of  logistics  support  information  and  standards  and  to  monitor  accomplishment  of 
specific  cooperative  logistics  programs, 

•  Acquisition  and  Cross  Servicing  Agreements  (ACSAs), 

•  Host  Nation  Support  (HNS), 
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•  Cooperative  Military  Airlift  Agreements  (CMAAs), 

•  War  Reserve  Stocks  for  Allies  (WRSAs), 

•  agreements  for  acceptance  and  use  of  real  property  or  services,  and 

•  standardization  of  procedures  under  America/Britain/Canada/ Australia/New 
Zealand  (ABCANZ)  auspices. 

Also  included  are  agreements  focusing  specifically  on  logistics  and  other  defense  coopera¬ 
tion  agreements.  Such  agreements  are  those  recently  concluded  (1995/96)  with  several 
Middle  Eastern  countries.  In  these  agreements,  the  countries  furnish  logistics  support  to 
the  U.S.  Forces  deployed  during  regional  contingencies. 

23.3.2  Legal  and  Policy  Basis 

The  North  Atlantic  Treaty  Organization  Mutual  Support  Acts  of  1979  (dated  4  August 
1980),  as  amended  (Title  10  U.S.C.  §2341-2350),  is  now  known  as  the  Acquisition  and 
Cross  Servicing  Agreement  (ACSA)  Authority.  It  provides  two  distinct,  although  not  en¬ 
tirely  separate,  provisions  for  cooperative  logistics  support.  Title  10  U.S.C.  §2341  pro¬ 
vides  acquisition-only  authority  and  Title  10  U.S.C.  §2342  provides  cross-servicing 
authority,  which  includes  both  acquisition  and  transfer  authority.  For  further  details  on  the 
authority  granted  DoD  under  these  laws,  read  Chapter  1 1  of  the  International  Armament 
Cooperation  Handbook  (publication  details  given  at  Reference  2,  Section  23.5). 

23.3.3  Cooperative  Logistics  Support  Agreements 

DoDD  2010.9  provides  complete  details  on  responsibilities  and  procedures  for  acquiring 
and  transferring  logistics  support,  supplies,  and  services  under  the  authority  of  Title  10 
U.S.C.  A  brief  overview  of  the  most  common  types  of  general  logistic  agreements  fol¬ 
lows. 

23.3.3.1  Acquisition  and  Cross  Servicing  Agreements  (ACSAs).  These  provisions,  col¬ 
lectively  referred  to  as  ACSAs,  are  applicable  worldwide,  not  merely  to  NATO  nations. 
There  must  be  a  cross-serving  agreement  and  implementing  arrangements  (DoDD  2010.9) 
in  effect  prior  to  actual  transfers.  Chapter  98  of  DoD  7220.9-M,  DoD  Accounting 
Manual,  gives  information,  record-keeping  requirements,  and  reporting  procedures.  The 
ACSAs  must  primarily  benefit  the  interest  of  DoD  forward-deployed  Commands  and 
Forces.  The  ACSAs  are  not  grant  programs.  DoD  acquisition  personnel  must  ensure 
ACSAs  are  not  used  as  a  routine  source  of  supply  for  a  foreign  country.  Routine  foreign 
requests  for  desired  U.S.  defense  articles  and  services  should  be  addressed  through  FMS 
procedures  in  accordance  with  the  Security  Assistance  Management  Manual. 
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Categories  of  logistics  support,  supplies,  and  services  that  can  be  provided  under  ACS  As 
are  defined  in  Title  10  U.S.C.  §2350. 

23.3.3.2  Host  Nation  Support  (HNSl.  HNS  is  civil  and  military  assistance  (material,  per¬ 
sonnel,  or  services)  rendered  in  peace  or  war  by  a  host  nation  to  allied  or  fiiendly  forces 
and  organizations  located  on  or  in  transit  through  its  territory.  HNS  agreements  are  nor¬ 
mally  pursued  by  unified  and  Component  commands  under  overall  direction  of  the  Joint 
Chiefs  of  Staff  (JCS)  and  the  Deputy  Under  Secretary  of  Defense  (Logistics).  A  broad 
logistics  area  is  addressed  within  HNS.  Follow-on  arrangements  and  joint  planning  for 
logistics  lines  of  communications  are  particularly  important  to  ensure  continued  materiel 
flow  in  support  of  deployed  Forces  in  emergency  agreements. 

23.3.3.3  Cooperative  Military  Airlift  Agreements  (CMAAs).  Title  10  U.S.C.  §2350c 
authorizes  SECDEF,  after  consulting  with  the  Department  of  State,  to  enter  into  coopera¬ 
tive  military  airlift  agreements  with  allied  countries.  Subject  to  reimbursement  and  other 
provisions,  these  agreements  cover  transporting  foreign  military  personnel  and  cargo  on 
aircraft  operated  by  or  for  the  U.S.  Armed  Forces  in  return  for  reciprocal  transportation 
for  the  U.S. 

23.3.3.4  War  Reserve  Stocks  For  Allies  (WRSAi.  This  program  allows  for  the  stockpil¬ 
ing  of  U.S. -owned  war  reserve  materiel  during  peacetime  to  ensure  that  the  U.S.  is  able  to 
supplement  selected  allies’  sustainability  during  wartime  until  they  can  be  resupphed.  Any 
nation  hosting  such  a  stockpile  is  expected  to  fund  storage,  maintenance,  in-country  tran¬ 
sit,  and  other  WRSA-related  costs.  The  Congress  limits  the  value  of  assets  transferred 
into  WRSA  stockpiles  located  in  foreign  countries.  In  any  fiscal  year,  the  amount  is  limited 
to  the  security  assistance  specified  in  authorizing  legislation  for  that  same  fiscal  year. 

23.3.3.5  Acceptance  and  Use  of  Real  Property.  Title  10  U.S.C.  §2608  authorizes  DoD 
Components  to  accept  real  property,  service,  and  supplies  from  a  foreign  country  for  sup¬ 
port  of  any  element  of  the  U.S.  Armed  Forces  in  an  area  of  that  country. 

23.3.4  Cooperative  Logistics  Summary 

Each  participant  or  party  benefits  when  involved  in  a  cooperative  logistics  agreement. 

The  benefits  can  be  tangible,  sueh  as  the  support  the  U.S.  Naval  vessels  receive  when  in  a 
foreign  port;  or  the  benefits  can  be  intangible,  such  as  the  implied  benefit  to  the  foreign 
nation  of  having  a  visible  U.S.  Naval  presence  in  the  region.  Other  cases  are  more  obvi¬ 
ously  “quid-pro-quo”:  cross-servicing  agreements,  in  which  each  party  receives  the 
equivalent  of  the  materiel  or  services  provided  to  the  other.  Besides  the  obvious  material 
benefit,  such  agreements  have  the  effect  of  creating  relationships  between  the  parties, 
which  it  is  hoped  will  serve  to  strengthen  political  bonds.  DoD  acquisition  personnel  in¬ 
volved  in  research,  development  and  acquisition  activities  should  be  aware  of  and  support 
such  efforts.  They  should  ensure  the  cooperative  support  mechanisms  described  above  are 
used  in  an  appropriate  manner  to  support  forward-deployed  Forces,  rather  than  as  a  means 
to  avoid  use  of  FMS  or  other  armaments  cooperation  mechanisms  described  in  this  chapter. 
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23.4  SECURITY  ASSISTANCE 


23.4.1  Introduction 

The  following  material  briefly  addresses,  in  general  terms,  the  complex  and  changing  sub¬ 
ject  of  security  assistance.  The  Management  of  Security  Assistance  (See  Reference  1, 
Section  23.5)  addresses  four  security  assistance  program  Components  that  require  U.S. 
Government  funding  and  two  Components  that  do  not  use  U.S.  doUars.  This  section  will 
summarize  these  six  programs.  Also,  the  referenced  publication  notes  that,  ‘The  DoD 
does  not  have  a  separate  logistics  system  to  support  foreign  military  requirements  resulting 
from  security  assistance  efforts.  Rather,  these  requirements  are  met  within  existing  DoD 
logistics  systems.” 

Security  assistance  program  components  include: 

•  Foreign  Military  Sales  (FMS)  Program  and  Foreign  Military  Construction  Sales 
(FMCS)  Program  (not  U.S.  Government  funded), 

•  Direct  Commercial  Sales  (DCS)  licensed  under  the  AECA,  (not  U.S.  Govern¬ 
ment  funded), 

•  The  Foreign  Military  Financing  Program  (FMFP), 

•  The  International  Military  Education  and  Training  (IMET)  Program, 

•  The  Economic  Support  Fund  (ESF),  and 

•  Peacekeeping  Operations  (PKO). 

23.4.2  Legal  and  Policy  Basis 

Quoting  from  The  Management  of  Security  Assistance  (Reference  1,  Section  23.5),  “Se¬ 
curity  assistance,  as  a  U.S.  Government  program,  is  governed  by  U.S.  statutes.  The  pri¬ 
mary  or  basic  laws  are  the  Foreign  Assistance  Act  (FAA)  of  1961,  as  amended,  and  the 
Arms  Export  Control  Act,  as  amended.  Funds  are  appropriated  for  security  assistance  in 
the  annual  Foreign  Operations,  Export  Financing,  and  Related  Programs  Appropriation 
Act.  Notwithstanding  certain  security  assistance  sales  programs,  such  as  foreign  military 
cash  sales  and  commercial  sales  which  do  not  involve  funding  authorizations  or  appro¬ 
priations,  the  Congress  still  has  an  interest  in  these  programs  and  has,  over  the  years,  in¬ 
corporated  certain  reporting  and  control  measures  in  the  law  affecting  these  as  well  as  ap¬ 
propriated  program.” 
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23.4.3  Security  Assistance  Programs/Logistics 


23.4.3.1  Foreign  Military  Sales  and  Foreign  MUitarv  Construction  Sales.  FMS  is  a 
nonappropriated  program  through  which  eUgible  foreign  governments  purchase  de¬ 
fense  articles,  services,  and  training  from  the  U.S.  Government.  The  purchasing  gov¬ 
ernment  pays  aU  costs  that  may  be  associated  with  a  sale.  In  essence,  there  is  a  signed 
govemment-to-government  agreement,  normally  documented  in  a  Letter  of  Offer  and  Ac¬ 
ceptance  (LOA).  Each  LOA  is  commonly  referred  to  as  a  “case”  and  is  assigned  a  unique 
identifier  for  accounting  purposes.  Under  FMS,  military  articles  and  services,  including 
training,  may  be  provided  from  DoD  stocks  or  fi'om  new  procurement. 

Cooperative  Logistics  Supply  Support  Arrangements  (CLSSAs)  are  FMS  agreements  for 
the  furnishing  of  secondary  items  from  the  U.S.  logistics  system  to  a  country  in  support  of 
specific  major  end  items/systems.  DoD  considers  the  CLSSA  to  be  one  of  the  most  effec¬ 
tive  means  to  replenish  the  in-country  stocks  of  spares  and  repair  parts  that  were  initially 
furnished  with  end  items  of  equipment.  FMS  CLSSA  agreements  set  out  terms  under 
which  DoD  provides  supply  support  for  a  common  weapon  system  to  a  foreign  govern¬ 
ment  or  international  organization  on  a  basis  equal  to  that  provided  to  U.S.  Forces. 
Availability  of  such  support  is  of  paramount  importance  in  promoting  interoperability  as 
well  as  in  marketing  U.S.  manufactured  weapon  systems.  Department  of  Defense  manual 
(DoD-M)  5105.38M  provides  guidance  for  CLSSAs. 

FMCS,  as  authorized  by  the  AECA,  involves  the  sale  of  design  and  construction  services 
to  eligible  purchasers.  The  construction  sales  agreement  and  sales  procedure  generally 
parallel  those  of  FMS. 

23.4.3.2  Direct  Commercial  Sales  Licensed  under  the  AECA  .  The  FAA  includes  direct 
commercial  sales  as  an  element  of  security  assistance  for  congressional  oversight  pur¬ 
poses.  These  are  sales  made  by  U.S.  industry  directly  to  a  foreign  buyer.  Unlike  FMS, 
direct  commercial  sales  transactions  are  not  administered  by  DoD  and  do  not  involve  a 
govemment-to-government  agreement.  Rather,  the  U.S.  Governmental  “control”  proce¬ 
dure  is  accomplished  through  licensing  by  the  Office  of  Defense  Trade  Control  in  the  De¬ 
partment  of  State. 

23.4.3.3  The  Foreign  Military  Financing  Program.  The  program  consists  of  congression- 
aUy  appropriated  grants  and  loans  that  enable  eligible  foreign  governments  to  purchase 
U.S.  defense  articles,  services,  and  training  through  FMS  or  direct  commercial  sales  chan¬ 
nels. 

23.4.3.4  The  International  Mihtarv  Education  and  Training  Program.  This  program  pro¬ 
vides  training  in  the  United  States  and  in  overseas  U.S.  miUtary  facihties  to  selected  for¬ 
eign  military  and  related  civilian  personnel  on  a  grant  basis.  It  also  includes  participation 
by  national  legislators,  who  are  responsible  for  oversight  and  management  of  the  military. 
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23.4.3.5  The  Economic  Support  Fund.  This  fund  is  to  promote  economic  and  political 
stability  in  areas  where  the  United  States  has  special  political  and  security  interests  and 
where  the  U.S.  has  determined  that  economic  assistance  can  be  useful  in  helping  to  secure 
peace  or  to  avert  major  economic  or  political  crises.  The  ESF  can  be  made  available  on  a 
grant  basis  for  a  variety  of  economic  purposes,  including  balance  of  payments  support, 
infrastructure  and  other  capital  and  technical  assistance  development  projects.  The  United 
States  Agency  administers  ESF  for  International  Development  (AID)  under  the  overall 
policy  direction  of  the  Secretary  of  State. 

23.4.3.6  Peacekeeping  Operations.  For  the  past  several  years,  PKO  provided  funds  for 
the  Multinational  Force  and  Observers  that  implemented  the  1979  Egyptian-Israeli  peace 
treaty  and  the  U.S.  contribution  to  the  United  Nations  Forces  in  Cyprus.  The  funding  al¬ 
locations  for  FY  1996  and  1997  support  the  African  Crisis  Response  Force,  Haiti,  Multi¬ 
national  Force  and  Observers,  and  the  Europe  Regional/Organization  for  Security  and 
Cooperation  in  Europe,  plus  several  other  programs.  The  Congress  has  shown  interest  in 
a  wide  range  of  similar  programs  that  may  be  funded  in  the  future  while  funding  of  exist¬ 
ing  programs  may  terminate. 

23.4.4  Security  Assistance  Logistics  Summary 

Logistics  is  the  element  of  security  assistance  that  has  allowed  it  to  function  as  a  major 
instrument  of  our  national  security  and  foreign  policy.  As  noted  in  The  Management  of 
Security  Assistance  (Reference  1,  Section  23.5),  security  assistance  serves  U.S.  interests 
by  assisting  allies  and  friends  to  acquire;  maintain;  and,  if  necessary,  employ  the  capability 
for  self-defense.  Also,  for  countries  in  regions  in  which  the  U.S.  has  special  security  con¬ 
cerns,  such  assistance  helps  them  attack  the  causes  of  economic  and  pohtical  instability. 

23.5  REFERENCES 

1 .  The  Management  of  Security  Assistance,  Defense  Institute  of  Security  Assis¬ 
tance  Management,  Wright-Patterson  AFB,  Ohio,  Sixteenth  Edition,  April 
1996. 

2.  International  Armaments  Cooperation  Handbook,  Office  of  the  Deputy  Under 
Secretary  of  Defense  (International  and  Commercial  Programs),  June  1996. 

3.  The  DISAM  Journal  of  International  Security  Assistance  Management,  Vol. 
19,  No.  2,  Winter  1996-97. 
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PARTY 


IMPLEMENTING  LOGISTICS 


24 

PRODUCTION 


You  can  run  but  you  cannot  hide  from  logistics. 

Truism 


24.1  LOGISTICS  OBJECTIVES 

The  logistics  objectives  during  the  production  phase  are  to  ensure  that  approved  support- 
abiUty  design  requirements,  i.e.,  such  as  Reliabihty  and  Maintainabihty  (R&M),  are 
achieved  in  the  early  production  articles;  and  they  also  ensure  that  planned  logistics  sup¬ 
port  resources  are  defined  and  adequately  funded  to  achieve  the  system  readiness  objec¬ 
tives.  The  Logistics  Manager  (LM)  should  insist  on  evidence  of  demonstrated  R&M,  a 
producible  design,  proven  repeatability  of  manufacturing  procedures  and  processes,  and 
logistics  support  verified  in  operational  testing.  (See  Table  24 A.) 

The  production  phase  is  an  extremely  challenging  period.  Some  programs  may  not  suc¬ 
ceed  in  production,  in  spite  of  having  passed  the  required  milestone  design  reviews.  Re¬ 
liability  and  support  characteristics  that  are  not  “designed-in”  cannot  be  “tested-in”  or 
“produced-in.”  There  may  be  unexpected  failures  during  the  test  program  that  require 
design  changes.  The  introduction  of  these  changes  can  impact  quality,  producibility, 
supportabihty,  and  can  result  in  program  schedule  slippages.  The  LM  must  exercise 
strong  configuration  management  discipline  during  this  transition  period  to  ensure  that 
the  changes  incorporated  in  the  system  are  properly  reflected  in  the  support  system 
deUverables. 


TABLE 24A 

SUPPORT  ACTIVITIES  DURING  PRODUCTION 


•  Verify  R&M  objectives. 

•  Monitor  production  of  prime  and  support  hardware/ 
software/GFE. 

•  Coordinate  and  provide  all  items  of  support. 

•  Update  support  and  deployment  planning. 

•  Obtain  operational  feedback  ASAP. 

•  Consider  logistics  implications  and  testing  of  ECPs. 

•  Monitor  training  programs. 
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The  transition  process  and  early  stages  of  production  are  impacted  by: 


•  design  maturity  -  a  qualitative  assessment  of  the  implementation  of  concur¬ 
rent  and  effective  design  pohcy; 

•  test  stabihty  -  the  absence  or  near  absence  of  anomahes  in  the  failure  data 
from  development  testing;  and 

•  certification  of  the  manufacturing  processes  -  includes  both  design  for  pro¬ 
duction  and  proof  of  process.  (Proof  of  process  occurs  during  pilot  produc¬ 
tion,  low-rate  initial  production,  or  other  “proof  of  concept”  methods  used 
prior  to  rate  buildup.) 

24.2  VARIABILITY-REDUCTION  PROCESS 

Variabihty-Reduction  Process  (VRP)  is  a  disciplined  design  and  manufacturing  approach 
aimed  at  meeting  customer  expectations  and  improving  the  development,  manufacturing, 
and  repair  processes  while  minimizing  time  and  cost.  The  traditional  approach  to  im¬ 
proving  a  product  is  tightening  tolerances  and  increasing  inspections.  The  alternative 
VRP  approach  seeks  to  reduce  causes  of  harmful  variation  in  the  production  process  and 
minimize  the  effects  of  the  variation  on  rehabihty  and  repeatability  of  the  system. 

24.2.1  Support  Readiness  Reviews 

The  PM  or  LM  should  consider  support  readiness  reviews  to  address  all  logistics  ele¬ 
ments.  The  number  of  reviews  and  the  topic  sequence  depend  on  the  nature  of  the  pro¬ 
gram.  Depending  on  the  system  under  consideration  and  the  phase  of  the  program,  some 
elements  will  be  more  critical  than  others.  The  emphasis  on  key  program  issues  will  have 
to  be  tailored  accordingly. 

Early  support  readiness  reviews  should  be  incorporated  in  PreUminary  Design  Reviews 
(PDRs)  and  Critical  Design  Reviews  (CDRs),  where  the  LM  has  an  active  role  in  estab- 
hshing  system  and  development  specifications.  Logistics  risk  areas  that  were  revealed 
during  the  PDR  and  CDR  should  be  prime  considerations  during  later  support  readiness 
reviews.  The  LM  should  participate  in  these  reviews  through  an  appropriate  Integrated 
Product  Team  (IPT). 

24.2.2  Tasks,  Activities  and  Deliverables 

The  quahty  and  validity  of  many  of  the  products  of  the  supportabihty  analyses  are  put  to 
the  test  in  the  production  phase.  Early  vahdation  of  the  output  from  the  analyses  provides 
confidence  in  the  quality  of  the  analytical  side  of  the  process.  As  the  program  enters  the 
production  phase,  a  lengthy  list  of  problems  requiring  resolution  by  the  LM  may  surface. 
Examples  of  these  problems  include  inadequate  support  equipment;  late  ordering  of 
spares;  inadequate  training;  documentation  that  is  not  to  the  latest  configuration;  unproven 
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facilities;  and  insufficient  sets  of  check-out  equipment  to  simultaneously  support  produc¬ 
tion  testing,  quality  assurance  standards,  and  deployment. 

24.2.3  Support  Requirements  Review  during  the  Production  Phase 

The  LM  should  take  stock  of  the  lessons  learned  from  the  results  of  the  Engineering  and 
Manufacturing  Development  (EMD)  phase  by  conducting  a  support  requirements  review 
before  recommending  that  the  program  proceed  to  the  production  phase.  Some  questions 
to  ask  follow: 

•  Have  critical  supportability  design  deficiencies  identified  during  Development 
Test  and  Evaluation  (DT&E)  and  Operational  Test  and  Evaluation  (OT&E) 
been  corrected,  or  have  solutions  been  identified  that  can  be  applied  before 
deployment? 

•  Have  logistics  elements  (support  equipment,  technical  manuals,  etc.)  been 
fully  evaluated  in  a  representative  operational  environment? 

•  Have  deficiencies  been  corrected,  or  can  they  be  eorrected  before  deployment? 

•  Have  quantitative  requirements  for  logisties  elements  (e.g.,  maintenance 
staffing  and  initial  provisioning)  been  determined? 

•  Is  sufficient  funding  included  in  the  Program  Objective  Memorandum  (POM)? 

•  Can  the  staffing  required  to  support  the  system  be  satisfied  by  the  Services 
personnel  projeetions? 

•  Will  produetion  lead  times  for  the  logistics  elements  support  the  planned  pro¬ 
duction  and  deployment  schedules? 

•  Have  tests  and  simulations  confirmed  the  attainability  of  system  readiness 
thresholds  within  the  target  levels  for  Operations  and  Support  (O&S)  eosts? 

•  Have  plans  for  interim  contractor  support,  if  applicable,  and  transition  to  or¬ 
ganic  support  been  prepared? 

If  these  issues  have  not  been  resolved,  the  LM  should  develop  a  recovery  plan  and/or 
recommend  further  system  development. 

24.2.4  Logistics  Manager’s  Priority  Tasks  during  the  Production  Phase 

The  primary  purpose  of  the  aequisition  process  is  to  deploy  systems  that  not  only  perform 
their  intended  functions  but  also  are  ready  to  perform  these  functions  repeatedly  without 
burdensome  maintenance  and  logistics  efforts.  The  successful  deployment  of  a  reliable 
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and  supportable  system  requires  that  the  LM  provide  strict  watchdog  management  during 
the  production  phase  to  ensure  that  adequate  technical  engineering,  manufac¬ 
turing  disciplines,  and  management  systems  are  applied  to  the  logistics  elements 
and  supportabihty  features  of  the  system.  Priority  items  for  the  LM  include: 

•  providing  timely  and  adequate  funding  for  all  logistics  elements; 

•  involving  logistics  specialists  in  the  preparation  of  comprehensive 
hardware  and  software  design  specifications; 

•  continuing  to  conduct  supportabihty  analyses; 

•  ensuring  logistics  input  to  configuration  control  and  the  comprehensive  assess¬ 
ment  of  the  impact  of  changes  on  all  logistics  elements;  and 

•  estabUshing  a  technical  management  system  for  tracking  support  equipment  re- 
habihty,  configuration  control,  and  compatibihty  with  end  item  hardware/ 
firmware/software. 
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25 

DEPLOYMENT/FIELDING 

Deployment:  As  used  herein,  deployment  is  a  generic  term  covering  the  ac¬ 
tivities  known  as  fleet  introduction  in  the  Navy,  site  activation  in  the  Air 
Force,  materiel  fielding  in  the  Army,  and  fielding  in  the  IT/AIS  community. 

25.1  HIGHLIGHTS 

In  this  Chapter,  several  deployment/fielding  highlights  will  be  diseussed,  including: 

•  deployment  planning  requirements  and  schedules; 

•  deployment  coordination  and  negotiation  requirements; 

•  the  deployment  plan,  agreement  and  certification;  and 

•  deployment  process  management. 

25.2  INTRODUCTION 

25.2.1  Purpose 

This  Chapter  will  provide  a  managerial  overview  of  the  actions  required  to  successfully 
deploy  a  new  or  modified  system. 

The  term  deployment,  as  used  here,  includes  fielding,  turnover,  hand-off,  fleet- 
introduction  and  other  terms  used  by  the  Services  for  the  initial  introduction  of  a  system 
to  operational  commands.  Deployment  planning,  execution,  and  follow-up  requirements 
will  be  discussed.  They  cover  the  period  firom  the  Concept  Exploration  (CE)  phase  until 
the  last  unit  is  operational. 

25.2.2  Objective 

The  deployment  process  is  designed  to  turn  over  newly  acquired  or  modified  systems  to 
users  who  are  being  and  have  been  trained  and  equipped  to  operate  and  maintain  the 
equipment.  All  organic  or  contractor-operated  elements  of  logistics  must  be  in  place  at 
appropriate  levels  at  the  time  of  deployment.  Although  it  may  seem  a  straightforward 
process,  deployment  is  complex  and  can  be  costly  if  not  properly  managed.  When  prop¬ 
erly  planned  and  executed,  deployment  can  make  a  major  contribution  toward  mission 
achievement  if  planned  levels  of  unit  readiness  are  met,  planned  costs  are  not  exceeded, 
and  logistics  turmoil  is  minimized. 
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25  J  MANAGEMENT  ISSUES 


253.1  Scope 

Deployment  challenges  the  Service  logistics  organization  with  providing  adequate  sup¬ 
port  to  a  system  when  custody  of  that  system  shifts  to  a  user  or  operating  command.  At 
that  point,  the  Service  logistics  capabiUty  may  be  augmented  for  various  periods  or  per¬ 
petually  by  a  range  of  contractor-provided  services.  In  fact,  DoD  5000.2-R  directs  Aat 
these  services  be  used  for  appropriate  programs  by  stating,  “Where  they  are  available, 
cost-effective,  and  can  readily  meet  the  user’s  requirements,  commercial  support  re¬ 
sources  shall  be  used.” 

First  unit  Initial  Operational  Capability  (IOC),  a  possible  start  date  for  deployment  re¬ 
sources  to  be  in  place,  may  range  from  the  first  day  of  custody  of  the  system  hardware  to 
some  later  date  when  unit  training  has  been  completed  and  a  readiness  inspection  is  satis¬ 
factorily  passed.  The  type  of  deplo5nnent  program  may  range  from  introduction  of  thou¬ 
sands  of  combat  vehicles  over  a  10-year  period  to  the  staged  delivery  and  acceptance  of  a 
single  aircraft  carrier.  Regardless  of  the  number  of  items  and  the  length  of  the  deploy¬ 
ment  schedule,  there  must  be  a  comprehensive,  coordinated  deployment  plan.  This  plan 
must  contain  realistic  lead  times  that  are  supported  by  adequate  funds  and  staff  and  that 
have  the  potential  for  rigorous  execution.  Applicable  elements,  among  those  identified  in 
Figure  25-1,  must  be  available  on  schedule  or  the  system  will  not  be  operational. 

Although  a  deployment  schedule  may  be  estabhshed  at  Milestone  I,  subsequent  adjust¬ 
ments  are  possible  and  should  be  considered,  particularly  in  the  early  stages  of  a  program 
when  a  greater  range  of  flexibihty  exists.  In  later  stages  of  the  acquisition  process,  the 
failure  to  meet  a  logistics  milestone  can  translate  either  into  a  costly  deployment  delay  or 
deployment  of  a  system  that  cannot  meet  readiness  goals.  Either  one  will  result  in  re¬ 
duced  mission  capabihty. 

25.3.2  Planning 

Deployment  should  not  be  thought  of  as  simply  deUvering  equipment.  There  is  a  need 
for  consideration  of  manpower,  personnel  and  training  requirements,  establishment  of 
facilities,  placement  of  system  support,  use  of  contractor  support,  data  collection  and 
feedback,  scheduling,  and  identification  of  funds.  Planning  for  deployment  and  using  an 
Integrated  Product  Team  (IPT),  as  appropriate,  begins  in  the  CE  phase  as  an  integral  part 
of  the  systems  engineering  process.  Reference  is  made  to  the  logistics  performance  re¬ 
quirements  stated  in  the  Operational  Requirements  Document  (ORD).  By  Milestone  I,  a 
draft  logistics  plan  is  recommended  to  address  the  long-term  deployment  considerations. 
Deployment  planning  intensifies  through  the  Program  Definition  and  Risk  Reduction 
phase  so  that  by  the  Engineering  and  Manufacturing  Development  (EMD)  phase,  a 


25-2 


Figure  25-1;  Deployment  Requirements 
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Figure  25-2:  Deployment  Activities 


detailed  plan  for  deployment  can  be  prepared.  This  plan  must  be  updated  and  coordi¬ 
nated  on  an  ongoing  basis  to  reflect  program  changes. 

Dissemination  of  information  to  all  participants  and  IPTs  is  very  important;  each  change 
must  be  coordinated  as  needed  and  passed  on  to  every  organization  involved  in  the  de¬ 
ployment  process.  Figure  25-2  shows  the  relationship  between  deployment  activities  and 
major  logistics  activities.  Changes  in  almost  any  aspect  of  the  program  (ranging  from  the 
very  obvious,  such  as  production  schedule  changes,  to  a  less  obvious  change  in  unit  man¬ 
ning  requirements)  can  have  an  impact  on  deployment.  Figure  25-3  provides  suggested 
generic  topics  for  inclusion  in  the  plan.  The  logistics  manager  must  be  actively  involved 
in  deployment  planning. 


SYSTEM  SUPPORT  DETAILS 

A.  Limitation  of  data 

B.  Logistics  support  concept 

C.  Deployment  agreement  and  certification  (LOA,  MOU)* 

SYSTEM/END  ITEM  DESCRIPTION 

A.  Functional  configuration 

B.  Organizational  and  operational  concepts 

C.  Deployment  schedules 

LOGISTICS  SUPPORT  AND  COMMAND  AND  CONTROL 

A.  Command  and  control  procedures 

B.  Logistics  assistance 

C.  Materiel  defects 

D.  Coordination 

SUPPORT  REQUIRED  FROM  USING  COMMAND 

OTHER  CONSIDERATIONS 

A.  Key  correspondence 

B.  Plans  and  agreements 

C.  Developers  checklist 

D.  User  command  checklist 

E.  Classified  information 

*  Letters  of  agreement,  memorandum  of  understanding 


Figure  25-3:  Typical  Deployment  Considerations 


25.3.2.1  Test  and  Evaluation.  Supportabihty  of  a  system  should  be  demonstrated  before 
deployment.  The  logistics  manager  must  ensure  that  the  Test  and  Evaluation  Master  Plan 
(TEMP)  includes  supportability  objectives,  issues,  and  criteria.  Development  and  opera- 
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tional  testing  during  EMD  provides  information  for  the  Milestone  IE  production  approval 
decision  and  provides  input  to  follow-on  testing  requirements.  These  tests  should  pro¬ 
vide  assurance  that  the  proposed  logistics  concepts  and  planned  resources  will  be  suffi¬ 
cient  to  support  the  system  once  deployed.  This  testing  may  also  suggest  changes  to 
planned  deployment  actions.  In  addition,  the  Follow-On  Test  and  Evaluation  (FOT&E) 
may  use  the  first  unit  equipped  as  the  test  unit;  FOT&E  planning  must,  therefore, 
be  closely  coordinated  with  deployment  planning. 

25.3.2.2  Logistics  Plans.  Contract  performance  specifications  have  an  impact  on  de¬ 
ployment  planning  and  execution.  An  early  fielding  analysis  plan,  in  terms  of  desired 
performance,  should  be  considered  as  a  contractor  task  and  an  IPT  action  item  during 
EMD.  This  plan  should  be  revised  as  input  data  changes.  Typical  input  data  changes  re¬ 
sult  from  changes  in  deployment  quantities  and  schedules  and  changes  in  manpower  and 
personnel  requirements  or  availability.  Early  fielding  plans  assist  logistics  management 
and  the  IPT  by  assessing  desired  performance  in  terms  of  many  elements.  Among  the 
elements  considered  are  the  impact  of  the  introduction  of  new  systems  on  existing  sys¬ 
tems,  the  identification  of  sources  of  personnel  to  meet  the  requirements  of  the  new  sys¬ 
tems,  the  impact  of  a  program’s  failure  to  obtain  all  the  logistics  support  resources,  and 
the  essential  logistics  support  resource  requirements  for  an  operational  environment. 

Early  plans  for  fielding  should  consider  addressing  actions  to  alleviate  potential  fielding 
problems  impacting  performance  i.e.,  risk  analysis. 

25.3.2.3  Funding.  Specific  funding  requirements  for  deployment  require  early  identifi¬ 
cation  in  terms  of  programming  and  budgeting.  Deployment-related  funding  re¬ 
quirements  may  include  mihtary  construction,  training,  travel,  transportation  of  mate¬ 
riel,  and  contractor  support;  and  they  can  involve  both  the  program  management  office 
(PMO)  and  user  funds.  Program  Managers  (PMs)  need  clear  visibility  and  control  over 
such  funds  to  accomplish  deployment  goals. 

25.3.2.4  Warranties.  The  logistics  manager  must  participate  in  the  selection  of  essen¬ 
tial  performance  requirements  to  be  warranted  in  the  production  contract.  Typically, 
warranties  are  on  system  or  component  reliability.  The  procedures  for  processing  war¬ 
ranties  should  mminuze  impact  on  the  user,  particularly  at  the  organizational  level.  War¬ 
ranty  provisions  should  enable  the  user  to  make  warranty  claims  without  delaying  essen¬ 
tial  maintenance  needed  to  restore  system  availability.  Some  years  ago,  the  Navy  estab¬ 
lished  warranties  that  allow  Navy  personnel  to  perform  needed  maintenance  and  then  re¬ 
cover  the  cost  incurred  from  the  contractor. 

When  a  warranty  is  to  be  used,  the  user  must  be  involved  in  the  planning;  and  the  war¬ 
ranty’s  impact  must  be  accommodated  in  the  deployment  plan.  The  deployment  plan 
should  state  which  components  are  under  warranty,  by  whom  and  for  how  long,  the  per¬ 
formance  parameters  covered,  and  the  starting  date  or  event  of  the  warranty.  It  is  often 
necessary  to  describe  warranty  provisions  by  equipment  serial  numbers.  The  interface 
between  the  user  and  the  contractor  should  be  explained  in  the  plan. 
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Warranty  coverage  often  begins  when  the  item  is  aceepted  by  the  government  and  deliv¬ 
ered  to  its  first  destination.  If  the  first  destination  is  a  storage  depot  (despite  DoD  effort 
to  reduce  warehouse  stocks)  and  the  warranty  period  is  measured  in  elapsed  time,  a  por¬ 
tion  or  all  of  the  warranted  fife  may  expire  before  the  item  is  placed  into  use.  Under  these 
circumstances,  it  is  preferable  to  seek  warranty  coverage  that  begins  when  the  item  is 
placed  into  service  or  coverage  that  is  based  upon  a  measure  of  usage  such  as  miles 
driven  or  elapsed  operating  time.  A  more  comprehensive  discussion  of  warranties  is 
contained  in  Chapter  19  of  this  Guide. 

25.3.2.5  Management  Information  System  (MIS).  The  logistics  manager  should  estab¬ 
lish  a  MIS  to  assist  with  the  deployment  planning  and  implementation  processes.  The 
number  of  logistics  elements,  the  varied  disciplines  involved  in  planning  for  deployment, 
the  numerous  funding  sources  for  support,  and  the  multitude  of  interrelated  data  items 
make  the  deployment  status  difficult  to  track  and  update  unless  it  is  managed  systemati¬ 
cally.  For  example,  a  slippage  in  parts  dehvery  for  a  simulator  could  mean  that  more 
training  time  is  needed  on  the  prime  system.  This  would  increase  demands  on  mainte¬ 
nance  (during  a  training  period)  and  increase  the  demand  for  replenishment  spares.  The 
increased  demand  for  spares  could  impact  the  availability  of  components  for  the  produc¬ 
tion  line  or  the  initial  support  package  for  following  deployments  and,  thus,  cause  a  slip¬ 
page  in  the  deployment  schedule.  Slippage  in  the  deployment  schedule  would  increase 
the  demand  for  support  to  the  system  being  phased  out  -  aU  the  result  of  shppage  in  parts 
for  the  simulator.  In  addition,  failure  rates  and  operating  problems  could  differ  signifi¬ 
cantly  from  those  encountered  in  the  testing  environment.  These  difficulties  must  be  fed 
back  to  the  logistics  manager  so  the  support  deficiencies  can  be  corrected.  As  a  mini¬ 
mum,  on-site  data  collection,  reports  of  tradeoff  analyses,  status  of  support  activities,  and 
costs  and  funding  reports  should  be  included  in  the  MIS. 

25  J.3  Coordination  and  Negotiation 

Estabhshment  of  a  deployment  IPT  should  be  considered.  The  group  should,  at  a  mini¬ 
mum,  have  members  from  the  using  and  supporting  commands.  Figure  25-4  depicts  rep¬ 
resentative  participants  and  responsibilities. 

Deployment  can  involve  negotiation  of  a  major  agreement,  certification  by  the  PM  to  de¬ 
liver  the  system  and  its  support,  and  certification  by  the  user  to  prepare  for  its  receipt. 
The  agreement  may  be  an  integral  part  of  the  plan  for  deployment  as  it  is  negotiated  be¬ 
tween  the  two  principals  and  coordinated  among  the  many  other  participants  and/or  IPT 
members.  Negotiations  should  commence  before  the  production  decision  and  should  be 
documented  as  required  by  each  Service.  For  example,  in  the  case  of  the  USAF,  the 
turnover  agreement  in  the  past  has  been  documented  in  the  Air  Force  program  manage¬ 
ment  plan.  The  coordination  may  involve  on-site  meetings  to  coordinate  the  details  of 
transfer,  site  planning  and  inspection,  equipment  on-site  checkout,  and  similar  activities. 
The  initial  units  to  receive  a  new  system  frequently  compete  for  replacement  spares  with 
the  ongoing  production  fine  and  with  the  build-up  to  support  subsequent  deployments. 
Depot-level  component  repair  may  also  compete  with  the  production  fine  for  resources 
(test  equipment,  bits  and  pieces,  skilled  personnel,  etc.).  These  problems  are  com- 
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pounded  when  the  fielded  reliabiUty  does  not  meet  the  planned  rehabihty.  The  priorities 
established  for  satisfying  requirements  during  this  time  of  support  and  production  build¬ 
up  should  be  included  in  the  agreement. 


COMMAND/STAFF 

RESPONSIBILITIES 

Program  Management  Office 

•  Estabhshes  working  group 

•  Develops  supportabihty  testing  assessment 

•  Provides  input  to  training  plans 

•  Prepares  deployment  plan 

•  Coordinates  plan 

•  Prepares  deployment  agreement  or  certification 

•  Negotiates  Agreement  or  Certification  with  Us¬ 
ing  Command(s) 

User  Commands 

•  Prepares  operational  support  plan 

•  Provides  input  to  deployment  plan 

•  Negotiates  agreement  or  certification  with  PMO 

Test  and  Evaluation  Organization 

•  Performs  OT&E,  FOT&E 

Training  Command 

•  Provides  input  to  deployment  plan 

•  Prepares  training  plans  and  system  training  re¬ 
quirements 

Service  Staff 

•  Provides  deployment  allocations,  personnel 
changes,  training  facihties  and  logistical  inputs 
to  the  deployment  plan 

•  Reviews  plans  and  agreements 

Contractor 

•  Provides  support  warranty 

•  May  provide  technical  interim  or  hfe-cycle 
maintenance  and  supply  support 

Figure  25-4;  Deployment  General  Responsibilities 


25.3.4  Organization 

As  the  planning  for  deployment  intensifies,  the  PM  should  estabhsh  an  organization  or 
IPT  within  the  PMO  to  assist  the  user,  interact  with  the  working  groups,  and  resolve 
problems  that  arise  during  deployment.  Deployment  personnel  should  be  considered  for 
both  PMO  and  on-site  assignments.  Teams  or  IPTs  may  be  required  for  briefing  and  as¬ 
sisting  user  commanders  and  their  staffs.  System  deployment  teams  on  site  can  assist  in 
the  checkout  of  equipment,  help  perform  the  hand-off,  train  unit  personnel,  and  assure 
that  support  capabihties  are  in  place.  The  assistance  of  contractor  personnel  is  often  de¬ 
sirable  at  this  time  and  should  be  considered  in  the  planning. 
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253.5  Materiel  Release  Review 


The  release  of  the  first  system  to  each  major  user  activity  follows  a  period  of  extensive 
planning  and  coordination.  The  materiel  release  review  (a  formal  Army  activity  that  is 
applicable  to  all  Services)  is  a  control  mechanism.  It  verifies  that  all  materiel  and  logis¬ 
tics  deficiencies  identified  in  OT&E  have  been  corrected  and  that  all  logistics  resources 
required  to  support  the  initial  deployment  will  be  available  concurrently  with  the  release 
of  the  system.  (See  Figure  25-1.)  The  materiel  release  is,  in  essence,  a  certification  by 
the  developing  activity  that  all  conditions  required  to  achieve  initial  readiness  have  been 

met. 

253.6  Lessons  Learned  from  Previous  Deployments 

Figure  25-5  summarizes  problem  areas  associated  with  previous  deployments/fieldings 
and  suggested  corrective  actions.  In  addition,  a  comprehensive  database  called  Auto¬ 
mated  Lessons  Learned  Capture  and  Retrieval  System  (ALLCARS),  is  the  Air  Force  les- 
sons-leamed  database.  It  is  managed  in  the  Aeronautical  Systems  Center  by  the  Program 
Director  for  the  Deskbook  Joint  Program  Office  (ASC/SYM)  at  Wright-Patterson  AFB, 
OH.  ALLCARS  hosts  lessons  learned  from  the  Combined  Automated  Lessons  Learned 
(CALL)  program.  Contributing  members  are  the  Air  Force,  Navy,  FAA,  and  NASA; 
each  member  is  responsible  for  the  content  of  their  data. 

ALLCARS  seeks  to  close  the  gap  between  DoD  organizations,  U.S.  Government  agencies, 
and  the  defense  industry  by  archiving  and  making  available  the  document^  experiences  of 
customers  and  maintainers  of  government  equipment.  It  is  a  central  repository  for  unclassi¬ 
fied  lessons  learned.  If  you  have  questions  or  comments,  you  may  contact  ALLCARS  at: 

Address;  ASC/SYM,  Bldg.  16 

2275  D  Street 

WPAFB,  OH  45433-7233 

Phone;  DSN  785-0423  or  commercial  513-255-0423 
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COMMON  PROBLEM  AREAS 


CORRECTIVE  ACTIONS 


Personnel  Turnover 

Document  all  plans,  agreements,  and  changes. 

Conduct  new  equipment  training  close  to  the  date  that 
the  unit  will  be  equipped. 

Conditional  Materiel  Release 

User  must  understand  and  agree  to  the  terms  of  a  con¬ 
ditional  materiel  release. 

Training  of  Operations  and  Maintenance 
Personnel 

Software  training  is  required  before  ATE  delivery  so 
the  unit  will  be  better  prepared  to  participate  in  the  ac¬ 
ceptance  testing. 

New  equipment  training  must  include  provisions  for 
the  maintenance  of  equipment  used  in  training.  Con¬ 
tractor  personnel  may  be  considered  for  this  task. 

Developer  should  brief  operational  commanders  and 
their  staffs  periodically  prior  to  deployment. 

Developer  must  ensure  all  required  support  equipment 
is  available  prior  to  new  equipment  training. 

Personnel  should  be  scheduled  for  new  equipment 
training.  They  should  have  the  correct  skills,  sufficient 
time  remaining  in  the  unit,  and  meet  all  other  training 
prerequisites. 

The  use  of  videotapes  and  other  media  should  be  con¬ 
sidered  for  new  equipment  training  teams. 

Establishing  a  PMO  Deployment  Team 
(Field  Support) 

Experienced  fielding  personnel  who  are  logisticians 
familiar  with  the  system  are  needed.  Start  looking  for 
these  people  early. 

Warranties 

Establish  simple  procedures  for  returning  failed  parts  to 
the  manufacturer  for  analysis. 

Deployment  Plan  for  a  Nonlogistics  Sig¬ 
nificant  Item 

A  plan  may  not  be  necessary,  but  the  user  must  concur 
with  the  decision  to  eliminate  the  plan. 

Contractor  Involvement  in  Deployment 
Plaraiing 

Keep  the  contractors  informed  of  requirements  so  they 
can  assess  their  tasks. 

Contracts  must  be  negotiated  to  ensure  support  items 
are  delivered  concurrently  with  the  end  item. 

Hardware  Problems  During  User  Hand-off 
Period 

Establish  a  staging  area  (may  be  at  contractor’s  facility) 
where  maintenance  personnel  can  check  out  all  equip¬ 
ment. 

Figure  25-5:  Common  Deployment  Problems 
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25.4  RISK  MANAGEMENT 


25.4.1  Funding  Reduction 

25.4.1.1  Risk  Area.  The  risk  area  involves  the  reduced  funding  from  the  Acquisition 
Program  Basehne  (APB)  values. 

25.4. 1 .2  Risk  Handling.  Because  cost  is  an  independent  variable,  performance  and 
schedule  tradeoffs,  in  the  final  analysis,  are  aU  that  is  available  other  than  pro^ana  termi¬ 
nation,  to  accommodate  a  reduction  in  planned  funds  other  than  program  termination. 

The  number  of  units  procured  (if  more  than  one)  can  be  thought  of  as  either  a  perform¬ 
ance  or  schedule  issue.  Risk  handUng  requires  that  objective  functions  be  conceived  for 
various  points  on  the  time-line  of  the  program.  These  functions  should  define  how  per¬ 
formance  and/or  schedule  are  related  to  cost,  in  order  to  help  in  the  performance  of  trade¬ 
off  analyses.  Such  objective  functions  should  be  evaluated  as  to  their  validity  and  sensi¬ 
tivity  tests  performed.  Only  in  this  way  can  the  PM  be  somewhat  prepared  for  the  in¬ 
creasingly  severe  financial  future  facing  the  Department  of  Defense. 

25.4.2  Schedule  Slippage 

25.4.2.1  Risk  Area.  A  risk  area  is  the  failure  to  understand  how  a  schedule  sUppage  in 
one  functional  element  impacts  the  other  elements  and  milestone  events. 

25.4.2.2  Risk  Handling.  The  PM  should  employ  a  network  schedule,  such  as  the  critical 
path  method,  which  identifies  all  deployment  activities  and  annotates  the  critical  path  of 
those  activities  that  would  delay  deployment  if  not  accompUshed  on  schedule. 

25.4.3  Delayed  Facilities  Planning 

25.4.3.1  Risk  Area.  Failure  to  perform  timely  facility  planning  can  result  in  substantial 
deployment  delays. 

25.4.3.2  Risk  Handling.  Facihty  requirements  that  are  included  in  the  military  construc¬ 
tion  program  normally  have  a  planning  and  funding  cycle  of  five  years.  In  the  case  of 
NATO  requirements,  the  cycle  may  run  up  to  seven  years.  Early  identification  of  re¬ 
quirements  and  coordination  with  the  nulitary  construction  proponent,  therefore,  is  neces¬ 
sary,  and  a  facihties  support  plan  is  desirable. 

25.4.4  Updating  the  Deployment  Plan. 

25.4.4.1  Risk  Area.  Failure  to  keep  the  deployment  plan  updated,  complete,  and  coordi¬ 
nated  with  all  concerned  can  result  in  deployment  delays  and  problems. 

25.4.4.2  Risk  Handlinp.  As  requirements,  schedules,  and  responsibihties  change,  the 
fielding  personnel  in  the  PM’s  organization  must  be  informed  so  they  recognize  the  need 


25-11 


to  promptly  update  the  plan.  In  addition,  the  PM  must  also  ensure  that  the  plan  and  its 
changes  ^e  fully  coordinated  with  the  user  and  that  the  deployment  IPT  provides  the  ve¬ 
hicle  for  its  coordination  and  distribution.  Finally,  the  user  should  be  required  to  prepare 
a  plan  for  the  receipt  of  the  new  system  and  should  have  established  pohcy  and  proce¬ 
dures  regarding  the  preparations  for  receipt  of  the  new  system  by  its  subordinate  units. 

25.4.5  Managing  Problems  in  the  Deployment  Process 

25.4.5.1  Risk  Area.  Unreported  and  uncorrected  deployment  problems  can  seriouslv  dis¬ 
rupt  the  process. 

Risk  Handling.  Problems  need  to  be  quickly  identified,  reported,  and  solved. 
The  deployment  plan  should  provide  a  process  that  will  lead  to  the  rapid  correction  of 
deployment  problems  and  deficiencies.  On-site  program  management  and  contractor  per¬ 
sonnel  can  facilitate  the  identification  and  reporting  of  problems.  In  addition,  for  the 
benefit  of  future  deployments,  lessons-leamed  reports,  based  on  the  problems  and  their 
solutions,  should  be  submitted  to  the  appropriate  Service  agency. 

25.5  SUMMARY 


•  Deployment  is  a  key  event  in  the  acquisition  life  cycle.  Its  success  can  be 
evaluated  in  terms  of  how  closely  it  adheres  to  schedule,  how  smoothly  it  is 
achieved,  and  how  easily  the  user  establishes  the  ability  to  meet  and  sustain  the 
system  readiness  objective. 

•  The  success  of  the  process  is  directly  related  to  how  well  it  is  planned,  coordi¬ 
nated,  negotiated,  and  executed.  Major  points  are  as  follows: 

—  Deployment  planning,  as  part  of  logistics,  is  an  integral  part  of  the  system 
engineering  process  and  is  initially  addressed  in  the  CE  phase.  Logistics 
performance  requirements  are  documented  in  the  ORD  for  Major  Defense 
Acquisition  Pro^ams  (MDAPs)  and  Major  Automated  Information  Systems 
(MAIS)  acquisition  programs.  Deployment  planning  intensifies  during 
EMD,  and  it  reaches  a  peak  during  Phase  in  as  the  deployment  approaches. 

Extensive  coordination  and  negotiation  characterize  deployment.  It  deals 
with  many  long  lead-time  tasks,  e.g.,  facilities,  personnel,  provisioning  pro- 
eurement  of  training  devices,  and  spares  and  repair  parts. 

25.6  REFERENCES 

DoD  Acquisition  Logistics  Handbook,  MIL-HDBK-502,  30  May  1997,  USAMC  Logis¬ 
tics  Support  Activity,  Redstone  Arsenal,  AL  35898-7466 
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26 

READINESS  AND  SUSTAINMENT 


There’s  never  enough  time  to  do  logistics  right,  but  there’s 
always  enough  time  to  do  it  over . . .  and  over . . .  and  over. 

Overheard  in  the  PMO  trenches 


26.1  INTRODUCTION 

The  subjects  addressed  in  this  chapter  pertain  to  a  re-engineered  logistics  system  and  the 
future  battlespace,  and  they  express  the  philosophies  of  Dr.  Paul  G  Kaminski,  past  Under¬ 
secretary  of  Defense  for  Acquisition  and  Technology  (USD(A&R)).  Many  of  the  state¬ 
ments  made  are  paraphrased  from  speeches  made  while  he  was  serving  as  USD(A&R). 

In  view  of  the  forecasts  for  shrinking  future  DoD  appropriations,  there  is  a  pressing  need 
to  limit  acquisition  and  support  costs  and  to  apply  the  concept  of  Cost  As  an  Independent 
Variable  (CAIV).  The  logistics  slice  of  the  defense  budget  is  about  17  percent  of  the  DoD 
top  line  each  year;  it  is  roughly  equal  to  the  amount  spent  on  procurement  or  on  research 
and  development.  These  are  the  policies,  realities,  and  resources  that  are  available  to  pro¬ 
vide  a  seamless  logistics  partnership  for  a  force  being  designed  to  achieve  dominant  bat¬ 
tlefield  awareness  and  combat  superiority.  This  is  a  force  that  en:q)hasizes  fiilly  integrated 
intelligence  systems,  technologically  superior  weapons  systems,  and  re-engineered  logistics. 

26.1.1  Terms 

In  the  world  of  Acquisition  Reform  and  new  policy  issues  that  drive  DoD  strategy  and 
force  planning,  new  and  modified  terms  have  evolved.  Some  of  these  terms  impact  logis¬ 
tics,  some  are  logistics  concepts,  some  shade  the  meaning  of  old  logistics  terms,  some 
have  ill-defined  definitions  that  are  still  evolving,  and  several  of  them  overlap.  Most  relate 
to  the  concept  of  a  logistically  ready  force  capable  of  sustaining  its  logistics  capability 
within  resource  constraints.  Thus,  recognizing  the  inexactness  of  the  effort,  the  following 
approximate  definitions  are  offered  for  this  chapter: 

•  Readiness.  Readiness  is  a  state  of  preparation  (measured  against  a  set  of 
criteria)  of  forces  or  systems  to  meet  a  mission. 

•  Sustainment.  Sustainment  is  an  effort  to  ensure  that  a  system  continues  to 
meet  its  required  Reliability,  Availability  and  Maintainability  (RAM)  parame¬ 
ters,  considering  policies  such  as  CAIV. 
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•  Focused  logistics.  Forced  logistics  is  one  of  four  operational  concepts  origi¬ 
nated  by  the  Chairman  of  the  Joint  Chief  of  Staff  in  his  1996  document,  ’’Joint 
Vision  2010.”  The  other  three  concepts  are  dominant  maneuver,  precision  en¬ 
gagement,  and  fiill  dimensional  protection.  Focused  logistics  is  defined  as  the 
fusion  of  information,  logistics,  and  transportation  technologies  to  perform  the 
following  functions: 

—  provide  rapid  crisis  response; 

—  track  and  shift  assets  even  while  en  route;  and 

—  deliver  tailored  logistics  packages  and  sustainment  directly  at  the  strategic, 
operational,  and  tactical  level  of  operations. 

•  Logistics  partnership.  This  concept  foresees  a  closer  bond  between  the  war¬ 
fighter  and  the  logistician,  achieved  in  large  measure  by  the  three  guiding  prin¬ 
ciples  of  reduced  logistics  that  include  the: 

—  response  time  by  means  of  a  true  total  asset  visibility  program, 

—  footprint  achieved  by  reducing  support  equipment  and  consumables 
through  system  design/redesign  actions,  and 

—  infi-astructure  achieved  by  reducing  outdated  systems,  inefficient  or  excess 
organic  logistics  capability,  and  unnecessary  logistics  inventory. 

•  Lean  logistics.  This  term  was  first  used  by  the  Air  Force  to  describe  the  utili¬ 
zation  of  improved  transportation,  including  commercial  systems,  to  replace 
traditional  caches  of  “just  in  case”  inventory. 

•  Spares  modernization.  This  effort  is  essentially  the  same  as  technology  inser¬ 
tion  described  in  Sections  28.5  and  28.6  of  this  Guide.  It  includes  redesigning 
secondary  items  to  improve  system  reliability  and  maintainability  at  the  sub¬ 
system  and  component  level  and  reducing  system’s  life-cycle  cost;  all  of  these 
efforts  bring  a  significant  return  on  investment. 

•  Flexible  sustainment.  Closely  related  to  and  overlapping  spares  modernization, 
flexible  sustainment  seeks  to  reduce  life-cycle  costs  through  improving  the: 

—  use  of  tradeoff  analyses  during  initial  design, 

—  reliability  of  current  systems  through  re-design,  and 

—  systems  management  process  that  will  facilitate  technology  insertion. 

26.2  DISCUSSION  OF  LOGISTICS  PARTNERSHIP 
26.2.1  Reduced  Logistics  Response  Time 

The  opportunity  exists  today  for  DoD  managers  to  refine  the  support  system  and  achieve 
reduced  logistics  response  times.  They  need  to  think  in  terms  of  substituting  fast  trans¬ 
portation  and  real  time  information  for  layered  inventory  in  order  to  improve  logistics  re¬ 
sponse  times.  They  need  to  aggressively  substitute  the  ability  to  rapidly  transport  material 
for  the  very  costly  practice  of  maintaining  layers  of  redundant  material  stockpiled  around 
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the  world  "just  in  case"  the  warfighter  needs  it  at  some  specific  locale  quickly.  Today’s 
"just  in  case"  system  has  evolved  over  the  years  in  response  to  a  cumbersome  acquisition 
system,  which  provided  little  or  no  in-transit  asset  visibility  and  lacked  a  fast  and  respon¬ 
sive  transportation  system.  The  DoD  situation  today  mirrors  the  commercial  logistics 
sector  as  it  was  in  the  1950s. 

Similar  to  the  transportation  issue,  DoD  managers  must  substitute  valid  real-time  informa¬ 
tion  regarding  the  conplete  status  of  all  resources,  i.e.,  personnel,  weapons,  equipment, 
and  supplies,  for  the  current  practice  of  maintaining  redundant  capabilities.  DoD  must  de¬ 
velop  and  deploy  a  true,  total-asset  visibility  program. 

Commanders  and  logisticians  need  to  know  the  combat  readiness  status  or  state  vector  for 
each  force  element.  This  knowledge  must  include  the  logistics  posture  of  fiiendly  and  en¬ 
emy  forces  as  well  as  having  a  prediction  of  the  resupply  needs  of  each  force  element.  To 
rnmplete  the  logistics  picture,  available  support  and  the  need  for  future  support  must  be 
propagated  from  each  force  element  in  the  field  through  the  whole  support  system.  This  is 
the  true  definition  of  total  asset  visibility.  A  strong  linkage  exists  between  dominant  bat¬ 
tlefield  cycle  time  and  total  asset  visibility.  Without  the  latter,  the  former  is  seriously  de¬ 
graded. 

A  major  system  integration  effort  is  needed  to  unplement  this  logistics  concept.  It  was  Dr. 
Kaminski’s  feeling  that  most  of  the  enabling  technologies  have  been  developed.  Some  of 
the  information  technologies  that  could  immediately  be  brought  to  bear  include  bar  code 
tagging  technology;  RF  (radio  fi-equency)  smart  response  tags;  relational  database  sys¬ 
tems;  miniature  global  positioning  system  receivers  and  position  reporting  transmitters; 
satelhte  and  fiber  command  and  control  communications  links;  and  predictive  planning 
tools. 

26.2.2  Reduced  Logistics  Footprint 

There  is  a  tremendous  leveraging  effect  associated  with  reducing  the  amount  of  support 
equipment  and  consumables  that  the  warfighter  must  take  in  time  of  war.  This  is  espe¬ 
cially  important  in  the  early  stages  of  a  conflict  when  airlift  resources  are  scarce  and  before 
a  sealift  bridge  can  be  closed.  On  new  systems,  it  means  paying  attention  to  life-cycle 
costs  early  in  the  design  of  a  new  system.  The  message  here  is  that  back  end  sustainment 
costs  are  receiving  more  up-front  design  attention.  The  F-22  program,  for  example,  is 
committed  to  this  approach.  There  is  a  sizable  technology  maturation  effort  under  way  on 
the  F-22  program.  Each  technology  effort  must  "buy  its  way  onto  the  program"  in  terms 
of  reducing  life-cycle  cost  and  program  risk. 

To  support  these  investment  decisions,  there  is  a  fairly  well  developed  life-cycle  cost 
model  that  includes  estimates  for  operational  and  logistics  elements  like  unit-level  con¬ 
sumables,  training,  expendables,  depot  maintenance,  and  mission  personnel.  However, 
given  the  speed  with  which  new  systems  are  introduced  to  replace  those  already  in  the 
field,  the  Department  singly  cannot  wait  on  the  new  system  development  process  to  solve 
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the  logistics  footprint  problem,  DoD  must  create  the  proper  incentives  to  insert  new  tech¬ 
nologies  in  legacy  systems  in  order  to  improve  their  reliability,  maintainability,  and 
sustainability. 

26.2.3  Reduced  Logistics  Infrastructure 

Within  the  department,  the  warfighters  have  come  to  clearly  realize  that  every  logistics 
dollar  expended  on  outdated  systems,  inefficient  or  excess  organic  capability,  and  un¬ 
needed  inventory,  is  a  dollar  not  available  to  build  warfighting  capability.  There  is  little 
doubt  that  private  sector  logistics  support  can  be  substituted  for  DoD  organic  capabilities 
in  many  applications  with  greater  effectiveness,  less  cost,  and  no  added  risk.  In  this  re¬ 
gard,  the  Department  must  strike  the  proper  balance  between  efficiency,  effectiveness,  and 
risk. 

The  Department  has  made  substantial  progress  in  reducing  inventories  at  all  levels.  Critical  to 
these  projected  inventory  reductions  are  increased  use  of  commercial  support  alternatives  to 
meet  the  department's  materiel  requirements.  For  example,  the  Defense  Logistics  Agency  has 
reduced  its  wholesale  medical  inventory  by  60  percent  —  $380  million  —  since  1992  by  using 
commercial  distribution  methods  rather  than  DoD  warehouses  to  distribute  medical  supplies. 
They  also  achieved  the  shorter  response  times  that  are  available  through  local  commercial  dis¬ 
tributors.  Since  more  than  $22  billion  of  the  total  DoD  inventory,  nearly  30  percent,  is  com¬ 
prised  of  consumable  items,  such  as  medical  supplies,  these  initiatives  are  obviously  critical  to 
the  achievement  of  continuing  inventory  reductions.  Pilot  programs  are  not  enough.  The  De¬ 
partment  must  proceed  quickly  but  prudently  to  broadly  apply  the  lessons  learned  in  these  pilot 
programs. 

In  the  depot  maintenance  operations  area,  for  example,  evidence  indicates  that  industry 
support  can  substitute  for  much  of  the  traditional  organic  capabilities  within  the  Depart¬ 
ment  and  perform  these  functions  better,  quicker,  and  cheaper.  There  are  significant  op¬ 
portunities  to  save  tax  dollars  and  reduce  government  investment  in  the  logistics  infra¬ 
structure  by  increasing  the  use  of  these  private  sector  capabilities.  Being  consistent  with 
their  readiness  and  cost-effectiveness  objectives,  the  Department  must  also  pursue  the 
maximum  amount  of  widespread  private  sector  participation  in  disposal  and  distribution. 

The  time  is  past  for  testing  the  concept  with  pilot  programs  at  the  margin  of  the  logistics 
infi-astructure.  The  big  payoffs  of  outsourcing  and  privatization  are  yet  to  be  realized.  To 
realize  these  payoffs,  DoD  managers  must  think  more  broadly  of  privatization  and  out¬ 
sourcing.  In  particular,  they  must  pay  careful  attention  to  incentives  for  implementing  pri¬ 
vatization  and  outsourcing  initiatives.  There  are  sufficient  incentives  at  the  top  of  the  De¬ 
partment,  but  the  incentives  need  to  be  pushed  down.  This  occurs  when  organizations 
gain  ownership  by  sharing  the  savings. 

The  Department  is  truly  moving  beyond  adherence  to  the  old  conventional  wisdom  that 
dictated  owning  all  support  capabilities  for  the  warfighter.  The  effectiveness  and  effi¬ 
ciency  of  outsourcing  various  logistics  support  functions  has  been  selectively  tested,  and 
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the  tests  have  been  successfiiL  Now  the  immediate  challenge  is  to  move  forward  with 
widespread  deployment  of  similar  outsourcing  privatization  efforts  across  a  broad  front. 

26.3  SPARES  MODERNIZATION 


See  paragraphs  27.5  and  27.6  of  this  Guide. 

26.4  FI.EXIBLE  SUSTAINMENT 
26.4.1  Definitions 

The  following  definitions  appear  in  the  DoD  Flexible  Sustainment  Guide  of  23  January 
1996: 


•  Life-Cvcle  Logistics  (LCD.  A  means  of  using  supportability  and  affordability 
tradeoffs  during  the  system’s  engineering  process,  the  LCL  can  optimize  acqui¬ 
sition  of  logistics  and  operations  and  support  (O&S)  costs  while  providing  the 
best  support  package  for  the  operational  forces.  In  addition  to  cost,  other 
factors  such  as  changing  mission  requirements,  new  technology,  and  coii^o- 
nent  obsolescence,  may  affect  the  tradeoff  process.  Assessment  of  cost- 
effective  life-cycle  support  tradeoffs  should  be  accon^lished  throughout  the 
life  of  the  system. 

•  fIpyiHIp  .<;nstflinment  (FS).  FS  is  a  decision-point-driven  process  to  inplement 
acquisition  reform  in  an  orderly  manner  and  to  optimize  investment  strategies 
for  support.  FS  introduces  two  new  sub-processes,  reliability  based  logistics, 
and  trigger  based  item  management.  In  addition,  other  innovative  support  so¬ 
lutions,  such  as  procurement  of  Form-Fit-Function  Interface  spares,  perform¬ 
ance  warranties,  and  obsolescence  assessment  are  presented  as  cost-effective 
life-cycle  support  alternatives. 

•  Rpliahilitv  Rased  Logistics  (RBU.  RBL  is  a  process  that  recognizes  the  im¬ 
portance  of  designing  reliabihty  into  systems  in  order  to  reduce  the  fielded 
maintenance  support  infrastructure.  Specifically,  RBL  addresses  whether  an 
item  should  be  treated  as  a  consumable  or  a  repairable.  Decisions  must  be 
made  as  to  whether  the  item  requires  commercial  versus  organic  repair.  Also, 
the  method  of  support  must  be  determined  as  a  function  of  cost-effectiveness, 
considering  the  item’s  reliability,  technology  cycle,  and  useful  life. 

•  Trigger  Based  Item  Management  (TBM).  TBIM  is  a  proactive  approach  to 
assess  fielded  systems  trends  and  re-examine  the  support  structure  when 
“triggers”  (such  as  a  change  in  rehability  or  maintainabihty,  technology,  or 
diminishing  resources)  are  detected.  These  triggers  enable  Integrated  Product 
Teams  (IPTs)  to  take  ^propriate  action  before  a  support  issue  becomes  critical 
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•  Fonn-Fitness-Function  Interface  (F^I).  F^I  is  a  mechanism  to  link  design,  fab¬ 
rication,  and  support  capability.  This  capability  can  reside  in  the  same  organi¬ 
zation,  either  government  or  contractor.  Key  product  performance  character¬ 
istics  and  product  acceptance  criteria  are  specified.  However,  there  is  flexibil¬ 
ity  to  change  the  design  while  meeting  performance  requirements;  and  there  is 
additional  flexibility  to  change  the  manufacturing  processes  pertaining  to  the 
design.  The  end  item  performance  must  be  verified  to  demonstrate  that  it  is 
unaffected  by  the  design  and/or  process  change.  These  changes  must  consider 
total  life-cycle  cost  impacts  as  part  of  the  overall  decision  process.  Again, 
prior  customer  approval  of  changes  may  or  may  not  be  required,  depending  on 
the  demonstrated  capability  of  the  supplier.  Technology  insertion  without  the 
need  for  equipment  modification  can  often  be  accomplished  with  commercial 
substitutes.  (See  Chapter  21,  Section  21.1,  of  this  Guide  for  definitions  of  a 
commercial  item,  a  modified  commercial  item,  and  a  nondevelopmental  item.) 

•  Sustained  Maintenance  Planning  (SMPl.  SMP  is  a  process  that  encompasses 
continual  review  of  established  maintenance  plans  to  ensure  the  most  cost  ef¬ 
fective,  safe  maintenance  is  being  performed  on  in-service  support  systems. 
System  age,  changes  in  material  conditions,  failure  modes,  and  the  operational 
enviroimient  are  continuaDy  analyzed  to  ensure  that  safe,  affordable  readiness 
is  maintained.  Emphasis  is  placed  on  use  of  Reliability  Centered  Maintenance 
(RCM)  as  a  continual  life-cycle  process  to  establish  and  adjust  preventive 
maintenance  requirements. 

•  Logistics  Reliability.  Logistics  Reliability  is  a  measure  of  an  item’s  ability  to 
operate  without  placing  a  demand  on  the  logistics  support  structure  for  repair 
or  adjustment.  Logistics  reliability  recognizes  the  effects  of  placing  demands 
on  the  logistics  support  structure  without  regard  to  effect  on  function  or  mis¬ 
sion. 

26.4.2  Discussion 

FS  involves  spares  or  parts  and  includes  the  functions  of  item  managers  and  System  PMs. 

It  can  also  be  defined  as: 

•  the  use  of  performance-based  specifications  including 
—  F^I  specifications  and 

—  nongovermnent  standards; 

•  the  development  of  innovative,  cost-effective  life-cycle  solutions; 

•  a  logical  decision-point-driven  process;  and 

•  the  control  of  ownership  cost  by  systematically  in^roving  reliability. 
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Flexible  sustainment  is  accomplished  by: 

•  comparison  of  organic  and  commercial  support  options, 

•  assessment  of  support  trends, 

•  technology  insertion,  and 

•  up-firont  analysis  of  reliability  parameters. 

FS  consists  of  two  major  processes.  The  first  is  RBL,  which  deals  with  both  acquisition 
and  postproduction  support;  the  second  process  is  TBIM,  which  applies  to  fielded  sys¬ 
tems.  These  two  processes  are  interrelated  and  complement  each  other. 

When  properly  executed,  these  two  concepts  can  result  in  improvements  in  the  efficiency 
of  the  acquisition  process  and  offer  a  relative  reduction  in  near-term  and  life-cycle  support 
costs.  Both  processes  encourage  the  program  manager  to  use  cost-effective  tradeoffs  by 
taking  advantage  of  commercial  industrial  capabilities  and  practices  and  using  organic  ca¬ 
pabilities  where  appropriate. 

FS  is  a  product  of  Acquisition  Reform  initiatives  and  can  be  traced  back  to  an  Air  Force 
Materiel  Command-chartered  Performance  Based  Business  Environment  (PBBE)  inte¬ 
grated  product  team.  In  addition  to  FS,  this  team  addressed  the  supplier’s  past  perform¬ 
ance,  rating  systems,  and  key  processes.  Single-process  facilities,  training  integration,  and 
training  systems  were  also  reviewed.  When  employing  FS,  the  increased  use  of  these  six 
PBBE  areas  is  encouraged. 

26.4.3  Reliability  Based  Logistics 

The  RBL  portion  of  FS  suggests  that,  if  the  reliability  of  a  system  exceeds  the  system  life 
or  technology  cycle,  the  maintenance  concept  should  not  be  based  on  a  plan  that  includes 
an  expensive  organic  infrastructure.  Further,  RBL  emphasizes  the  importance  of  design¬ 
ing  reliability  into  systems.  Thus,  RBL  is  an  expansion  of  the  systems  engineering  process 
as  it  applies  to  subsystems  and/or  components.  Specifically,  RBL  addresses  the  consum¬ 
able  versus  repairable;  the  commercial  versus  organic  repair  decisions;  support  as  a  func¬ 
tion  of  an  item’s  reliability;  its  technology  cycle;  and  the  useful  life. 

Reliability  is  particularly  significant  in  RBL.  Evolving  high  reliability  components  and 
subsystems  favor  more  spare  deeisions  vice  repair  decisions.  Rapidly  changing  technolo¬ 
gies  lend  themselves  to  commercial  support;  stable  technologies  may  favor  organic  repair 
capability.  As  used  here,  the  term  repair,  deals  with  what  happens  to  an  item  after  it  is 
removed  and  replaced  on  the  platform;  however,  testability,  reparability,  training,  and  skill 
proficiency  are  important  factors  influencing  flexible  sustainment.  Organic  removal  and 
replacement  at  field  level  is  not  in  the  context  of  repair  during  this  discussion. 


26-7 


The  FS  guide,  referenced  in  Section  26.4.3  (Tools),  presents  a  reliability  based  logistics 
decision  tree.  This  decision  tree  can  be  employed  during  the  systems  engineer¬ 
ing/acquisition  logistics  support  processes.  It  is  an  expansion  on  the  overall  question  of 
spares  versus  repair  and  the  source  for  each.  Decision  points  on  the  tree  deal  with  the  re¬ 
liability  and  technology  life  cycle  as  applied  to  new  and  future  systems,  making  RBL  a  new 
way  of  doing  business. 

Ad^tionally,  elements  of  the  support  system  and  design  criteria,  as  well,  must  be  analyzed; 
their  sensitivities  must  be  established.  This,  or  any  logic  tree,  must  be  capable  of  intensive 
sensitivity  analysis  in  order  to  find  break  points  for  reliability  and  to  drive  design  goals  for 
major  subsystems  and  components.  Sensitivity  analysis  can  identify  life-cycle  cost  drivers 
early;  thus,  such  costs  can  be  minimized  while  attempting  to  minimize  any  degradation  of 
system  capabilities.  Sensitivity  analysis,  which  determines  the  life-cycle  impacts  on  re¬ 
source  consumption  and  operational  readiness,  also  identifies  the  cost  and  readiness  driv¬ 
ers  that  must  be  dealt  with  during  the  conceptual  phase. 


RBL  will  capitalize  on  existing  commercial  capabilities  by  using  contractor/govemment 
relationships  and  new  contracting  vehicles  and  language.  Contractor  and  government 
teams  must  fiiUy  trust  each  other,  adopting  insight  versus  oversight  as  a  fundamental  man¬ 
agement  style.  Contracts  need  to  employ  performance-based  warranties  where  they  make 
sense  and  truly  reduce  life-cycle  cost  to  the  government.  The  FS  Guide  provides  exam¬ 
ples  of  warranty  and  contractual  techniques  that  should  be  considered  and  tailored  to  the 
specific  needs  of  a  program. 

26.4.4  Trigger  Based  Item  Management  (TBIM) 

TRIM,  as  an  element  of  FS,  is  a  philosophy  that  recognizes  the  existence  of  both  mechani¬ 
cal  and  manual  indicators,  which  are  available  to  tell  item  managers  when  to  take  correc¬ 
tive  action  concerning  parts.  TBIM  is  a  proactive  approach  to  addressing  problems  of  de¬ 
ficiencies  associated  with  the  management  of  military  products.  It  uses  predetermined 
“parts”  or  conponent  “triggers”  or  trends  as  indicators  of  potential  problems.  These  trig¬ 
gers  act  as  prompts  for  the  management  team  to  take  appropriate  action  prior  to  the  situa¬ 
tion  becoming  critical.  The  increased  use  of  triggers  early  in  the  management  process  is  a 
key  to  unproved  support  posture  without  increasing  costs.  Triggers  can  include  change  in 
reliability,  change  in  technology,  or  vanishing  resources.  The  item  manager  should  have  a 
pre-planned  process  for  corrective  action  when  a  trigger  or  trend  it  is  required.  In  Sub¬ 
section  26.4.2.1,  the  manager  or  item  manager  is  offered  three  alternatives  to  use  when 
problems  approach.  The  decision  will  be  driven  by  the  long-term  rewards  of  improved 
efficiency  in  the  acquisition  process  and  a  reduction  in  both  near-term  and  life-cycle  cost. 

26.4.2. 1  Three  Corrective  Action  Alternatives.  One  alternative  for  corrective  action  is 
the  traditional  Build-To-Print  (BTP)  option  for  parts.  Secondly,  a  Modified  Build-To- 
Print  (MBTP)  option  allows  flexibility  for  a  capability  supplier  to  incorporate  improved 
manufacturing  processes  in  producing  the  specified  design  for  a  component.  The  third 
option  is  that  of  F^I  replacement,  where  product  requirements  are  conveyed  to  excellent 
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sources  in  strict  performance  terms.  In  this  option  the  contractor  is  responsible  for  the 
design  and  manufacturing  processes.  (A  source  for  a  model  for  spares  reprocurement  is 
given  in  Section  26.4.5  below.) 

26.4.5  Tools 

A  few  of  the  supporting  data  systems,  such  as  the  Naval  Aviation  Logistics  Data  Analysis 
(NALDA),  are  listed  as  a  source  of  possible  “triggers”  in  Appendix  J  of  the  23  January 
1997  issue  of  the  DoD  Flexible  Sustainment  Guide.  A  working  prototype  of  a  spares  re¬ 
procurement  model  (process  and  methodology)  is  available  through  the  Air  Forces  War¬ 
ner  Robins  Air  Logistics  Center.  The  World  Wide  Web  address  is: 

http://web-tech.robins.af.mil/~f3i/main.htm 

26.4.4  POC/Reference 

•  Naval  Air  Systems  Command,  Maintenance  Planning  and  Design  Interface  De¬ 
partment,  Air  3.2. 

•  Assistant  Deputy  Under  Secretary  of  Defense  (Logistics)  MPP &R. 

•  PBBE  products,  including: 

—  Program  Risk  Management  Guide 
—  Performance  Based  Contracting  Guide 
—  Performance  Based  Product  Requirements  Guide 
—  Key  Supplier  Process  Handbook 
—  Vertical  Contract  Change  Guide 

—  Contractor  Performance  Assessment  Report  (CPAR)  Form  and  Instruction 
—  Performance  Risk  Assessment  Group  (PRAG)  Guide 
—  Joint  Service  Guide  Specification  (JSGS)  (8) 

•  Statutes: 

—  10  use  §2464.  Core  Logistics  Functions 

—  10  use  §2466.  Limitations  of  the  Performance  of  Material 

_  10  use  §2469.  Contracts  to  perform  workloads  previously  performed  by 

depot-level  activities  of  DoD:  Requirements  of  Competition 

•  Data  System  Sources  (sample  sources  of  possible  “triggers”): 

—  NALDA  —  Naval  Aviation  Logistics  Data  System 

_  VAMOSC  —  Visibility  And  Maintenance  Operation  Support  Cost 

—  RISE  —  Recoverable  Item  Simulation  Capability  (D041B) 

—  PQDRS  —  Product  Quality  Deficiency  Reporting  System  (G021) 

_  WMER  —  Wholesale  Management  and  Efficiency  Reporting  System 

(D035B) 

_  STAMMIS  —  Standard  Army  Maintenance  Management  Information  System 
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27 

POSTPRODUCTION  SUPPORT  (PPS) 

Acquisition  Stratee\:  “Each  PM  shall  develop  and  document  an 
Acquisition  Strategy  that  shall  serve  as  the  roadmap  for  program 
execution  from  program  initiation  through  Postproduction  Support.  ” 

Industrial  Capability:  “Prior  to  production  termination,  Components 
shall  take  actions  to  ensure  there  will  be  adequate  industrial  capabilities 
and  capacity  to  meet  postproduction  operational  needs,  ” 

DoD  5000.2-R 


27.1  DISCUSSION 

The  terms  just-in-time  logistics  and  focused  logistics,  in  concert  with  Flexible  Sustainment 
(FS),  describe  the  logistics  support  system  (including  postproduction  support),  which 
DoD  is  striving  to  attain  by  the  year  2000.  Focused  logistics  will  be  the  fusion  of  infor¬ 
mation,  logistics,  and  transportation  technologies  to  provide  rapid  crisis  response,  to  track 
and  shift  assets  even  while  en  route,  and  to  deliver  tailored  logistics  packages  and  sus¬ 
tainment  directly  at  the  strategic,  operational,  and  tactical  level  of  operations.  Just-in-time 
logistics  connotes  a  sharp  reduction  in  the  warehousing  of  spare  parts,  combined  with 
rnmpftnsating  responsiveness  in  the  fabrication  and  transportation  elements  of  the  logistics 
systenL  The  common  thread  among  these  three  initiatives  (just-in-time  logistics,  focused 
logistics,  and  FS)  is  the  managerial  challenge  of  maintaining  readiness  at  a  substantially 
lower  cost  than  in  the  past,  i.e.,  developing  a  better,  more  cost-effective  way  to  provide 
logistics  support. 

The  actual  attainment  of  focused  logistics,  as  well  as  many  of  the  initiatives  conprising 
just-in-time  logistics,  lays  outside  the  purview  of  the  individual  acquisition  program. 
However,  the  resulting  macro  logistics  system  will  have  a  significant  impact  on  the  ac¬ 
complishment  of  postproduction  support. 

27.2  BACKGROUND  AND  OBJECTIVE 

The  objective  of  operational  and  postproduction  support  planning  is  to  maintain  the  sys¬ 
tem  in  a  ready  condition  throughout  its  operational  phase  within  Operations  &  Support 
(O&S)  cost  levels  documented  in  Life-cycle  Cost  (LCC)  estimates  and  acquisition  pro¬ 
gram  baselines.  Accordingly,  the  developer/Program  Manager  (PM)  of  Major  Defense 
Acquisition  Programs  (MDAPs)  and  Major  Automated  Information  Systems  (MAISs)  are 
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directed  by  DoD  5000.2-R  (which  serves  as  a  general  model  for  other  programs)  to  plan 
for  postproduction  support  as  part  of  the  overall  program  acquisition  strategy. 

Postproduction  support  planning  is  a  relatively  new  responsibility  for  PMs.  Prior  to  early 
1991,  operational  and  postproduction  support  planning  was  often  left  to  the  readiness  or 
commodity  commands  of  each  Service.  Developers  were  most  concerned  with  design, 
development,  production,  and  deployment  of  new  systems.  However,  senior  operational 
commanders  took  issue  with  this  process  because  of  the  support  problems  encountered  in 
maintaining  systems  in  mission-ready  condition.  Moreover,  readiness/commodity  com¬ 
mands  discovered  continuing  problems  in  providing  spares,  repair  parts,  and  technical  data 
because  data  packages  were  often  unsuitable  for  conqjetitive  procurement;  sole-source 
vendors  had  gone  out  of  business;  or  the  long-lead  time  for  production  would  not  meet 
urgency  requirements.  Hence,  the  Services  and  DoD  realized  that  the  development  proc¬ 
ess  must  embrace  a  true  “cradle-to-grave”  design  approach. 

Today,  the  PM  is  charged  with  the  responsibility  for  postproduction  planning.  Some 
would  argue  that  the  PM  has  enough  to  do  without  the  added  burden  of  this  effort.  How¬ 
ever,  if  we  consider  the  U.S.  marketplace  as  product  consumers,  what  are  our  expecta¬ 
tions  of  manufacturers  in  the  way  of  postproduction  support  of  appliances,  video  record¬ 
ers,  or  even  our  automobile?  When  contemplating  the  purchase  of  desktop  or  laptop  per¬ 
sonal  computers,  are  we  concerned  about  warranty,  technical  support,  or  the  adition  or 
replacement  of  components?  What  about  response  time?  These  are  indeed  important  is¬ 
sues  to  consider.  A  conpany  that  failed  to  meet  our  expectations  would  probably  not  do 
well  in  the  marketplace,  and  it  is  no  accident  that  manufacturers  give  significant  consid¬ 
eration  to  such  design  requirements.  The  military  user  must  also  have  a  comparably  high 
level  of  support  and  responsiveness  to  meet  their  readiness  requirements  and  mission  ob¬ 
jectives. 

27.3  METHODS 

Planning  for  postproduction  support  begins  in  the  Concept  Exploration  phase,  with  much 
of  the  detailed  planning  and  execution  starting  in  the  Engineering  and  Manufacturing  De¬ 
velopment  (EMD)  phase,  when  components  and  manufacturers  of  components  are  se¬ 
lected.  (See  Figure  27-1.)  Design  can  still  be  influenced  to  lessen  or  eliminate  any  poten¬ 
tial  postproduction  support  problems.  Development  will  take  place  using  performance 
specifications  in  lieu  of  the  detailed  specifications  used  in  the  past.  Interface  specifications 
will  be  designed  to  promote  open  system  architecture,  permitting  flexibility  in  accom¬ 
plishing  future  updates  and  technology  insertion.  This  early  planning  and  analysis  is  at  the 
heart  of  reliability  based  logistics.  The  analysis  effort  should  be  performed  by  or  under  the 
direction  of  an  appropriate  Integrated  Product  Team  (IPT),  and  the  government  members 
should  perform  any  segments  that  are  beyond  the  scope  of  the  EMD/Production  contracts. 
The  impacts  of  the  emerging  focused  logistics  system  and  reliability  based  logistics  efforts 
must  be  integrated  into  the  support  analysis,  with  the  expectation  that  spares  requirements 
will  be  favorably  affected.  Likewise,  items  that  are  single-source  or  those  that  the  gov¬ 
ernment  cannot  obtain  data  rights  for,  should  be  identified;  and  plans  should  be  laid  for 
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CONCEPT 

EXPLORATION 

♦  ESTABUSH  STABLE  PRODUCTION  BASE 

*  CONCURRENT  DEUVERY  OF  SYSTEM  & 

ITS  SUPPORT  INFRASTRUCTURE 

MSO 

PROGRAM  DEF& 
RISK  REDUCTION 

MSI 

ENGINEERING  &  MANUFACTURING 
DEVELOPMENT 

Msn 

PROD,  ilEIJ)lNG/DEPLOYMENT, 

&  OPERATIONAL  SUPPORT 
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•  Verify  R&M  objectives 

•  Monitor  production  of  prime  and  support  hardware/software/GFE 

•  Coordinate  and  provide  all  other  items  of  support 

•  Update  support  and  deployment  planning 

•  Obtain  operational  feedback  ASAP 

•  Consider  logistics  implications  and  testing  of  ECPs 

•  Monitor  training  programs 


Figure  27-1:  Time-Phased  Support  Activities 


appropriate  long-term  support,  e.g.,  organic  support  capability,  production-line  buy-out, 
or  contractor  logistics  support  agreements. 

Despite  the  best  planning  efforts,  support  problems  are  certain  to  occur  during  the  post¬ 
production  period.  The  digital  data  stored  in  the  Continuous  Acquisition  and  Life-Cycle 
Support  (CALS)  system  as  well  as  other  DoD  Component-specific  data  systems  will  be 
important  resources  in  analyzing  support  problems  and  developing  appropriate  corrective 
actions.  Identified  support  problems,  such  as  inadequate  sources  of  supply  or  repair, 
should  be  analyzed  to  determine  alternative  solutions,  the  costs  and  associated  risks  in¬ 
volved,  and  an  estimate  of  the  funding  and  other  actions  required  to  implement  preferred 
solutions. 

Service  lives  of  current  systems  have  been  extended  for  periods  far  beyond  those  originally 
planned.  As  a  consequence,  many  suppliers  are  no  longer  in  business  or  are  unwillmg  to 
accept  contracts  for  con^onents  that  they  originally  produced  in  the  distant  past.  There¬ 
fore,  new  sources  will  necessarily  have  to  be  brought  on  line  through  flexible  manufactur¬ 
ing  or  other  means.  Some  of  the  components  thus  affected  can  be  replaced  through  the 
use  of  performance  specifications,  but  others  will  likely  require  some  detailed  specifica¬ 
tions  to  properly  function  in  major  systems  designed  in  the  earlier  era  of  detailed  specifi¬ 
cations. 

Opportunities  to  lower  system  life-  cycle  cost  through  technology  insertion  should  be 
sought.  In  general,  succeeding  generations  of  technology  offer  both  improved  perform¬ 
ance  and  improved  supportabUity.  Once  identified,  a  potential  candidate  for  technology 
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insertion  should  be  recommended  through  appropriate  channels  for  inclusion  in  the  Reli¬ 
ability,  Maintainability,  and  Supportability  (RM&S)  depot  maintenance  modification  pro¬ 
gram. 

27.4  TIMING  AND  ISSUES 

Given  the  need  to  consider  postproduction  support  issues,  how  and  when  does  the  PM 
accon:q)lish  postproduction  support  planning?  First  you  need  to  understand  typical  issues, 
such  as: 

•  increased  parts  usage, 

•  inadequate  technical  data, 

•  technological  obsolescence, 

•  unacceptable  LCC, 

•  lost  vendor  capability  to  provide  spares/repair  parts,  and 

•  item  deleted  with  no  substitute. 

Using  a  ten-year-old  automobile  as  an  exanple,  what  do  you  expect  in  the  way  of  effective 
support  regarding  the  examples  above?  Is  it  cost  effective  for  manufacturers  to  make 
parts  for  a  declining  number  of  their  products  still  in  use?  At  what  point  should  they  halt 
production  of  spares?  Will  there  be  sufficient  demand  for  manufactured  parts?  Are  their 
original  vendors  still  in  business;  and,  if  so,  what  was  done  with  the  tooling  last  used  years 
ago? 

Accordingly,  if  the  need  to  conduct  postproduction  planning  is  accepted,  how  and  when  is 
it  done?  Planning  is  normally  a  govemment/contractor  effort  with  a  contractual  require¬ 
ment  for  the  contractor  to  develop  the  postproduction  support  plan,  which  is  subject  to 
government  coordination  and  approval.  Such  a  plan  normally  is  completed  by  Milestone 
in  and  updated  periodically  thereafter.  The  contractor  does  this  effort  as  part  of  an  over¬ 
all  supportability  analysis  structured  to  meet  the  PM’s  acquisition  strategy  of  “cradle-to- 
grave”  LCC  and  planning.  Figure  27-2  provides  a  generic  Postproduction  Support  (PPS) 
decision  process. 

27.5  DATA  COLLECTION 

Once  a  PPS  plan  has  been  created,  it  is  important  to  have  some  way  of  measuring  system 
readiness,  which  could  trigger  planned  actions  to  provide  effective  support  to  the  user. 
During  O&S  activities,  the  user  implements  a  Unit  Readiness  Reporting  system,  which 
rates  his  organizational  ability  to  meet  assigned  mission  requirements.  One  part  of  this 
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Figure  27-2;  Postproduction  Suppoit  Decision  Process 


report  comments  on  materiel/system  availability  and  offers  reasons  for  non-mission  ready 
systems.  Another  somce  of  measuring  system  performance  during  the  O&S  phase  is 
service  maintenance  data  collection  systems  including: 

•  Army  —  the  Army  Maintenance  Management  System  (TAMMS) 

•  Navy  —  maintenance  and  Materiel  Management  (3M) 

•  Air  Force  -  Core  Automated  Maintenance  System  -  Reliability  Maintenance 
Information  System  (CAMS  -  REMISS) 

•  All  Services  —  on-site  contractor  technical  representatives. 

This  information  and  other  sources  will  help  us  determine  the  specific  cause  of  perform¬ 
ance  degradation.  Exan^les  are  poor  component  reliability;  aging  systems;  or,  perhaps, 
improper  fault  identification.  Current  best  practices  include  efforts  identified  as  spares 
modernization,  lean  logistics,  flexible  sustainment,  and  other  traditional  sustainment 
remedies. 
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27.6  EXAMPLE 


The  Navy  F-14A/B  weapons  system  program  provides  an  example  of  technology  insertion 
as  a  part  of  postproduction  support.  The  program  office  initiated  a  project  to  replace 
older  mechanical  gyroscopes  with  modem  electronic  ring-laser  gyroscopes  in  each  aircraft. 
The  mechanical  gyroscopes  demonstrated  an  MTBF  of  40  hours;  and  the  ring-laser  gyros 
demonstrated  an  MTBF  of  4,500  hours,  which  was  more  than  a  100-fold  increase.  A  con¬ 
servative  analysis  (which  did  not  capture  all  of  the  cost  benefits  of  the  replacement) 
showed  that  the  break-even  point,  i.e.,  when  the  savings  repaid  for  the  initial  investment, 
occurred  in  the  fifth  year  of  operation.  Substantial  life-cycle  support  cost  savings  will  ac¬ 
crue  in  the  following  years  of  service  life  planned  for  the  F-14A/B  weapons  system.  Of 
course,  system  readiness  has  in^roved  fi'om  the  very  onset  of  the  replacement  program. 

27.7  POSTPRODUCTION  SUPPORT  PLANNING 

As  previously  noted,  a  postproduction  support  plan  is  normally  undertaken  as  a  joint  gov¬ 
ernment-contractor  efibrt  performed  during  EMD.  It  should  he  completed  prior  to  Mile¬ 
stone  ni  by  an  IPT  and  coordinated  with  other  appropriate  documents  and  the  actions  of 
other  IPTs.  The  postproduction  support  plan  should  be  maintained  as  long  as  the  system 
is  in  the  active  inventory  and  should  focus  on  issues  such  as: 

•  system  and  subsystem  readiness  objectives  in  the  postproduction  time  frame. 

•  organizational  structures  and  responsibilities  in  the  postproduction  time  frame 

•  modifications  of  planning  documents  to  accommodate  the  needs  of  PPS  planning 

•  resources  and  management  actions  required  to  meet  PPS  objectives 

•  assessment  of  the  impact  of  technological  change  and  obsolescence 

•  evaluation  of  alternative  PPS  strategies  to  accommodate  production  phase-out 
(second  sourcing,  standardization  with  existing  hardware,  engineering  level  of 
effort  contracts  in  the  postproduction  time  frame,  life-of-type  buys,  contract 
logistics  support  versus  organic  support,  maintenance  concept  change,  suitable 
substitute,  redesign,  flexible  computer  integrated  manufacturing) 

•  consideration  of  support  if  the  life  of  the  system  is  extended  past  the  original 
forecast  date 

•  data  collection  efforts  in  the  early  deployment  phase  to  provide  the  feedback 
necessary  to  update  logistics  and  support  concepts 

•  potential  for  foreign  military  sales  and  its  impact  on  the  production  run 
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•  provisions  for  the  use,  disposition  and  storage  of  Government  tools  and  con¬ 
tractor-developed  factory  test  equipment,  tools,  and  dies 

Table  27  A,  at  the  end  of  this  chapter  lists  additional  issues  that  should  be  addressed  in  post¬ 
production  support  planning. 

27.8  FSTABT  JSHING  A  COMPETITIVE  ENVIRONMENT 

Relying  on  a  single  industrial  source  for  critical  support  may  increase  risk  in  the  cost  and 
availability  of  spares  and  repair  parts  during  the  operational  phase  and,  particularly,  after 
termination  of  end-item  production.  The  Logistics  Manager  (LM)  should  consider  obtain¬ 
ing  technical  data,  drawings,  tooling,  etc.,  to  enable  the  Service  to  compete  foUow-on  logis¬ 
tics  support.  The  cost  of  obtaining  this  capability  should  be  weighed  against  the  potential 
benefits  of  competition,  particularly  during  an  extended  postproduction  period.  Detailed 
component  bre^out  plans,  initially  stated  in  the  acquisition  strategy  and  subsequently  up¬ 
dated  and  refined,  should  be  consulted.  (Note:  Historically,  the  government  has  not  done  a 
good  job  keeping  configuration  under  control  after  the  loss  of  production  experience, 
equipment,  and  drawings;  and  it  has  purchased  inadequate  technical  documentation  to  en¬ 
able  the  breakout  and  competition  of  equipment,  spares  and,  repair  parts.  Good  documen¬ 
tation  and  configuration  control  is  essential  if  the  government  is  to  successfully  compete  for 
follow-on  support.  It  may  be  advisable  to  have  the  major  manufacturer  continue  a  level  of 
effort  in  documentation  after  the  production  line  closes). 

27.9  PQSTPRODUCTION  SUPPORT  DECISION  MEETING 

The  PM  should  conduct  a  PPS  decision  meeting  prior  to  the  final  production  order  to  avoid 
major  nonrecurring  charges  (if  foUow-on  production  is  later  required)  and  to  update  the 
PPSP  based  upon  the  latest  data  available.  The  meeting  should  also  explore  the  advisability 
of  purchasing  items  from  the  manufacturer;  these  items  might  include  manufacturing 
structures,  forgings  and  castings,  insurance  items  to  cover  crash/battle  damage  or  fatigue, 
proprietary  data,  and  raw  material. 

27.9.1  Other  Remedies 

When  faced  with  the  imminent  loss  of  production  sources  for  unique  spares  and  repair 
parts,  there  are  two  basic  options  available  to  LMs:  they  are  to  increase  the  supply  or  de¬ 
crease  the  demand.  A  combination  of  actions  listed  in  Figure  27-3  is  often  the  most  practi¬ 
cal  approach.  These  remedies  are  generally  less  effective  and  more  costly  than  effective 
actions  taken  earher  in  the  production  cycle. 

27.10  FUNDING  OF  ENGINEERING  AND  PUBLICATIONS  SUPPORT 

There  is  generally  a  continuing  need  to  correct  hardware  design,  specifications,  and  soft¬ 
ware  after  the  completion  of  system  development.  Changes  to  technical  manuals  are  also 
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SPARE  AND  REPAIR  PARTS  ACTIONS 

INCREASE  SUPPLY 

DECREASE  DEMAND 

• 

Develop  a  reprocurement  technical  data 

•  Restrict  the  issue  to  critical  applications  in 

package  and  alternate  production  sources. 

support  of  combat  essential  items. 

• 

Withdraw  from  disposal  source. 

•  Phase  out  less  essential  systems  employing 
the  same  parts. 

• 

Procure  life-of-type  buy. 

•  Restrict  issue  to  system  applications  where 

• 

Seek  substitute  (interchangeable)  parts. 

no  substitute  is  available. 

• 

Redesign  system  to  accept  standard  compo¬ 
nents  if  not  interchangeable. 

•  Accelerate  replacement  of  the  system. 

• 

Purchase  plant  equipment;  establish  an 
organic  depot  capability. 

• 

Subsidize  continuing  manufacturing. 

• 

Draw  (cannibalize)  from  marginal,  low  prior¬ 
ity  systems. 

Figure  27-3:  Logistics  Actions  to  Reduce  Impact  of  Loss  of  Production  Sources 


needed  to  reflect  the  system  and  software  changes  and  to  correct  other  deficiencies  re¬ 
ported  by  operator  and  maintenance  personnel.  While  the  materiel  system  (end  item)  is 
still  in  production,  the  procurement  appropriation  bears  the  major  burden  of  these  costs. 
However,  an  abrupt  change  in  funding  responsibility  occurs  at  the  beginning  of  the  first 

Figure  27-4  is  a  notional  display  of  the  continued  funding  requirement  for  these  costs  ex¬ 
tending  into  the  0«&:S  phase.  While  the  total  requirement  for  engineering  and  publication 
support  should  decrease  as  initial  problems  are  detected  and  corrected,  the  total  burden 
for  such  costs  shifts  to  the  Operation  and  Maintenance  (O&M)  appropriation  after  the 
termination  of  system  production.  Early  recognition  of  the  need  for  postproduction  sup¬ 
port  and  the  programming  and  budgeting  of  O&M  fimds  are  required  to  maintain  a  conti¬ 
nuity  of  effort.  The  increase  in  fund  requirements  shown  in  the  late  postproduction  phase 
is  attributed  to  growing  design  obsolescence  and  wearout.  The  LM  should  work  directly 
with  his  supporting  O&M  appropriation  manager  to  develop  valid  requirements  estimates, 
which  are  usually  derived  from  experience  with  similar  systems,  and  the  LM  should  pro¬ 
gram  and  budget  accordingly. 
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Figure  27-4:  Sources  of  Engineering  and  Publication  Funding 


27.11  TIMELY  PPS  PLANNING 

Postproduction  support  planning  must  be  performed  when  acquisition  strategy,  design, 
and  documentation  options  are  still  available  for  incorporation  into  an  effective  PPSP.  To 
delay  the  planning  invites  the  risk  of  having  inadequate  engineering  and  financial  support 
for  sustained  system  readiness  and  availability.  The  PPSP  must  be  maintained  and  tied  to 
each  update  of  logistics  plans.  While  such  plans  are  essential  to  establishing  the  support- 
ability  and  readiness  of  the  materiel  system,  the  PPSP  is  crucial  to  maintaining  that  sup- 
portability  and  readiness  throughout  the  system's  life. 

27.12  SUMMARY 

•  The  first  empirical  measure  of  system  readiness  occurs  when  the  system  is  de¬ 
ployed  in  the  operational  phase. 

•  Readiness  and  R&M  experience  during  the  operational  phase  is  employed  to 
adjust  the  support  resources  that  were  programmed  during  the  EMD  and  Pro¬ 
duction,  Fielding/Deployment,  and  Operational  Support  phases. 

•  Performance  and  R&M  deficiencies  must  be  detected  and  corrected  as  early  as 
possible  in  the  O&S  phase  of  the  system. 

•  The  objective  of  planning  performed  during  system  development  is  to  ensure 
that  readiness  objectives  are  met  and  sustained  through  the  O&S  phase,  in¬ 
cluding  the  postproduction  period.  Planning  deferred  until  the  problems  are 
encountered  will  have  limited  effectiveness. 
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TABLE  27A 

POSTPRODUCTION  SUPPORT  CHECKLIST 

1.  Supply  Support 

a. 

Continued  producibility  and  availability  of  con^onents  and  parts.  (Peculiar 
items  within  the  system  should  be  reviewed  down  to  the  subcomponent  level 
and  national  stock  number.) 

(1) 

Is  technical  data  available  at  a  reasonable  cost? 

(2) 

Is  stabUity  of  design  a  concern? 

(3) 

Is  conpetitive  procurement  appropriate? 

(4) 

Is  the  production  base  adequate? 

(5) 

What  proprietary  rights,  if  any,  have  been  declared  by  the  prime  or 
subcontractors? 

(6) 

Are  rights  in  data  procurable  at  a  reasonable  cost? 

(7) 

What  is  life-of-type  buy  potential? 

(8) 

Are  repair  facilities  available? 

(9) 

Is  the  conq)onent  critical  to  system  performance? 

(10) 

What  is  the  expected  life  of  the  system/subsystem? 

(11) 

Is  there  FMS  support  potential? 

(12) 

Are  workaround  alternatives  available? 

(13) 

Are  quality  assurance  requirements  unique,  difficult  to  duplicate? 

(14) 

Is  contract  logistics  support  feasible? 

(15) 

Will  failure  rates  be  high  enough  to  sustain  organic  capability? 

(16) 

Technology  obsolescence.  Is  the  system  or  part  replaceable  with  new 
technology? 

(17) 

Will  potential  design  changes  eliminate  the  need  for  the  part? 

(18) 

Is  an  engineering  level-of-efifort  contract  appropriate  to  ensure 
continued  supportability? 

b. 

What  support  equipment  is  required? 

c. 

Will  support  of  support  equipment  be  available  at  a  reasonable  cost? 

d. 

Is  there  an  adequate  organization  to  focus  on  and  resolve  postproduction 
problems? 
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TABLE  27A(Coiit’d) 

POSTPRODUCTION  SUPPORT  CHECKLIST 


2.  Engineering 

a.  Who  has  been  designated  to  perform  acceptance  inspection  QA  on  tech  data? 

b.  Will  there  be  adequate  field  engineering  support,  configuration  management, 
and  ECP  support?  Will  there  be  adequate  support  to  update: 

(1)  Technical  manuals 

(2)  Production  drawings 

(3)  Technical  reports 

(4)  Logistics  support  data 

(5)  Operational  and  maintenance  data 

(6)  User's  manuals 

(7)  Data  requirements 

c.  Will  operational  experience  be  considered  in  changes  to  the  materiel  system? 

3.  Competitive  Procurement 

a.  Is  production  rate  tooling  conplex/cost  significant;  is  it  readily  available  to 
procure,  or  a  long  lead  item? 

b.  Are  all  cost  factors  associated  with  a  breakout/con:q)etitive  procurement  deci¬ 
sion  considered?  Cost  elements  should  encompass  added  tooling,  special  test 
equipment,  qualification  testing,  quality  control  considerations,  rights  in  data 
procurement,  etc.  If  performance  specifications  are  applicable,  the  following 
additinnal  costs  pertain:  cataloging,  bin  opening,  item  management,  technical 
data,  production  and  distribution  variables,  configuration  control  and  engi¬ 
neering  requirement  costs,  etc. 

c.  Are  an  potential  customers  included  in  the  production  requirements  computations? 

4.  ATE  Support 

a.  Hardware 

( 1 )  Will  hardware  be  supportable? 

(2)  Will  mission,  ECP  changes  be  compatible? 

(3)  Will  modifications  be  possible,  supportable? 

(4)  Is  system  expandable? 
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TABLE  2A  (Cont’d) 

POSTPRODUCTION  SUPPORT  CHECKLIST 


b. 

Software 

(1)  Will  diagnostic  software  changes  be  possible? 

(2)  Will  the  organizational  structure  allow  for  continuing  software  update? 

(3)  Win  software  changes  caused  by  ECP/mission  changes  be  incorporated? 

5. 

Storage  and  Handling 

a. 

Will  shelf-life  items  be  replaceable  when  they  expire? 

b. 

Will  special  shipping  containers  be  replaceable/repairable? 

c. 

Will  peculiar  manufacturing  tools  and  dies  be  procured  and  stored? 

6. 

Technical  Data 

a. 

Will  manufacturing  shop  standards  and  procedures  be  retained? 

b. 

Will  all  changes  that  occur  during  the  production  phase  be  incorporated  in  the 
manufacturing  shop  drawings? 

7. 

Training 

a. 

Will  simulators  and  maintenance  trainers  be  supportable  in  the  out  years? 

b. 

Will  follow-on  factory  training  be  required? 

8. 

Maintenance 

a. 

Will  depot  overhaul  be  required  in  the  out-years?  Organic  —  Contract. 

b. 

Will  provisions  be  made  in  the  front  end  to  accommodate  a  service  life  exten¬ 
sion  program  if  required?  (Most  recent  materiel  systems  have  been  extended 
well  past  their  original  forecasted  disposal  date). 

c. 

Will  components  be  available  to  support  the  depot  overhaul  program  in  the 
out-years? 

d. 

Is  it  realistic  to  co-mingle  manufacturing  with  repair  on  a  single  production 
line? 
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TECHNOLOGY  INSERTION/ 
MODinCATION  MANAGEMENT 

“In  actuality,  our  military  hardware  is  now  on  a  replacement 
cycle  of  about  54  years  -  this  in  a  world  where  technology 
typically  has  a  half-hfe  from  two  to  ten  years.” 

“America’s  High  Noon  Complex” 

Army  RD&A  Bulletin,  Sept-Oct  1994 


28.1  POLICY 

28.1.1  Open  Systems  Design 

An  open  systems  approach  shall  be  followed  for  all  system  elements  (mechanical,  electri¬ 
cal,  software,  etc.)  in  developing  systems.  This  approach  is  a  business  and  engineering 
strategy.  Specifications  and  standards  are  adopted  by  industry-standards  bodies  or  de 
facto  standards  (set  by  the  market  place)  for  selected  system  interfaces  (functional  and 
physical),  products,  practices,  and  tools.  Selected  specifications  are  based  on  perform¬ 
ance,  cost,  industry  acceptance,  long-term  availabiUty  and  supportability,  and  upgrade 
potential.  For  all  Command,  Control,  Communications,  Computers,  and  Intelligence 
(C"I)  systems;  information  systems;  and  weapons  systems  that  must  interface  with  C"l 
systems  or  information  systems,  mandatory  guidance  is  contained  in  the  Technical  Ar¬ 
chitecture  Framework  for  Information  Management  (TAFIM). 

28.1.2  Non-Traditional  Acquisition 

The  DoD  must  be  prepared  to  plan  and  execute  a  diverse  variety  of  missions.  To  meet 
the  user's  needs  in  a  timely  manner,  the  acquisition  system  must  be  able  to  rapidly  insert 
advanced  technology  directly  into  the  warfighter's  arsenal.  The  ability  to  rapidly  insert 
technology  demonstrates  new  and  improved  mihtary  capabilities  on  a  scale  adequate  to 
establish  operational  utility  and  affordable  cost.  Demonstrations  based  on  mature  tech¬ 
nologies  may  lead  to  more  rapid  fielding.  Where  appropriate,  managers  in  the  acquisition 
community  shall  make  use  of  non-traditional  acquisition  techniques,  such  as  Advanced 
Concept  Technology  Demonstrations  (ACTDs),  rapid  prototyping,  evolutionary  and  in¬ 
cremental  acquisition,  and  flexible  technology  insertion. 
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28.2  DEFINITIONS 


28.2.1  Open  System 

An  open  system  is  one  that  implements  sufficient  open  specifications  for  interfaces, 
services,  and  supporting  formats.  It  enables  utilization  of  properly  engineered  compo¬ 
nents  across  a  wide  range  of  systems  with  minimal  changes,  interoperabihty  with  other 
components  on  local  and  remote  systems,  and  interaction  with  users  in  a  style  that  facili¬ 
tates  portability.  An  open  system  is  characterized  by  the  following: 

•  well-defined,  widely  used,  and  non-proprietary  interfaces/protocols; 

•  use  of  standards,  which  are  developed/adopted  by  industrially  recognized 
standards  bodies; 

•  definition  of  all  aspects  of  system  interfaces  to  facihtate  new  or  additional 
systems  capabilities  for  a  wide  range  of  applications;  and 

•  explicit  provision  for  expansion  or  upgrading  through  the  incorporation  of  ad¬ 
ditional  or  higher  performance  elements  with  minimal  impact  on  the  system. 

28.2.2  Standards-Based  Architecture 

Standards-based  architecture  is  an  architecture  that  is  based  on  an  acceptable  set  of  stan¬ 
dards  governing  the  arrangement,  interaction,  and  interdependence  of  the  parts  or  ele¬ 
ments.  Together  these  elements  may  be  used  to  form  a  weapons  system  that  satisfies  a 
specified  set  of  requirements. 

28.2.3  Open  Systems  Architecture  (OSA) 

The  OSA  is  a  system  architecture  that  is  produced  by  an  open  systems  approach  and  that 
employs  open  systems  specifications  and  standards  to  an  appropriate  level. 

28.2.4  Open  Systems  Standards 

Open  systems  standards  are  standards  that  control  and  fully  define  attributes  for  software, 
hardware,  interface  design,  network  protocol,  circuit  board  design,  etc.  These  standards  ’ 
have  been  developed  and  maintained  in  a  commercial  consortium  or  higher  organization 
such  as  the  ISO  or  IEEE  group  consensus  process.  Standards  have  requirements  for 
compatibility  and  interoperability  at  the  interface,  but  they  do  not  define  the  performance 
of  a  given  product.  A  commercial  manufacturer  may  change  the  performance  of  a  prod¬ 
uct  without  government  knowledge  and  still  comply  with  the  standard.  (Consent  is  not 
required  since  the  government  is  now  only  another  customer.) 
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28.2.5  Cost  Definitions 


•  Oneration  and  Sunnort  (O&S^  Costs.  0«feS  cost  is  the  sum  of  the  system  opera¬ 
tions  and  maintenance  (O&M)  budget  appropriation;  the  military  personnel 
(MILPERS)  appropriation;  and  a  small  amount  of  costs  in  other  appropriations, 
e.g.,  military  housing  maintenance. 

•  Direct  O&M  Costs.  Direct  O&M  costs  comprise  fuel,  depot  maintenance,  depot- 
level  repairs  (DLRs),  interim  contractor  support  (ICS),  contractor  logistics  sup¬ 
port  (CLS),  consumables,  and  similar  expenditures. 

•  Indirect  O&M  Costs.  Indirect  O&M  costs  comprise  base  operations  support 
(BOS),  medical  support,  individual  training,  Permanent  Change  of  Station  (PCS) 
moves,  communications,  administration,  and  related  expenditures. 

•  System  Life  Cycle.  System  life  cycle  is  defined  as  the  time  from  Milestone  (MS) 
I  to  disposal.  It  includes  all  phases  of  the  system’s  life. 

•  Service  Life.  Service  life  is  the  total  system  usefulness  from  first  inception  to  fi¬ 
nal  phaseout. 

•  Age.  Age  is  the  measure,  at  any  given  point,  of  the  elapsed  time  since  a  system 
completed  production.  (Average  age  can  be  calculated  for  an  entire  fleet.) 

28.3  BACKGROUND 

For  a  number  of  years,  the  U.S.  military  budget  has  been  shrinking  rather  markedly;  and 
the  portion  of  the  budget  available  for  new  weapons  system  procurement  has  shrunk  the 
greatest.  O&S  costs  have  been  more  resistant  to  near-term  shrinkage.  In  1996,  the 
Commandant  of  the  Marine  Corps  stated  that  the  Marine’s  workhorse  Sea  Knight  heli¬ 
copters  would  be  50  years  old  before  they  are  replaced  in  2017.  In  1994,  the  Air  Force 
Scientific  Advisory  Board  projected  the  following  aircraft  equipment  age  at  retirement. 
These  projections  are  based  on  current  trends  and  foreseeable  appropriation  levels; 


AIRCRAFT 

TYPE 

NUMBER  OF 
AIRCRAFT 

AVERAGE  AGE 
NOW,  years 

PROJECTED 

RETIREMENT 

AGE  AT  RETIRE¬ 
MENT,  years 

C/KC-135 

638 

33 

2040 

79 

B-52 

94 

34 

2030 

70 

C-5A 

77 

25 

2021 

52 

C-141 

248 

29 

2010 

45 

C-130  (20 

vrs  and  older) 

439 

30 

2030 

66 

F-15 

940 

12 

2020 

38 

F-16 

1727 

7 

2020 

33 
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The  same  age  trends  apply  to  virtually  all  Army,  Navy,  and  Air  Force  weapons  systems. 
Thus,  there  is  a  pressing  need  to  find  ways  to  decrease  the  operating  costs  of  the  current 
weapons  systems  and  increase  subsystem  capabilities  (including  reliability  and  maintain¬ 
ability)  through  technology  insertion. 

The  insertion  of  technology  improvements  before,  after,  or  during  the  production  phase  is 
accomphshed  whenever  feasible  to  enhance  system  capability,  rehability,  or  both.  The 
key  facilitator  to  technology  insertion  is  open  systems  architecture.  The  following  dis¬ 
cussion  focuses  on  the  logistics  aspects  of  technology  insertion  and,  hence,  on  cost¬ 
saving  and/or  reliability-enhancing  initiatives. 

28.4  OPEN  SYSTEMS  DESIGN;  A  PREREQUISITE 

An  open  systems  approach  for  systems  provides  a  foundation  for  lower  life-cycle  costs 
and  improved  systems  performance  through  use  of  standards-based  architectures  and 
greater  access  to  commercial  technology,  products,  and  processes.  A  framework  for  open 
systems  implementation  is  achieved  by  addressing  the  key  considerations  of  interfaces, 
architecture,  risks,  and  supportabihty. 

28.4.1  Interface  Management 

Interface  management  is  an  important  element  to  open  systems  design.  A  process  should 
be  used  to  select  interface  standards,  which  employ  minimal  criteria  (openness,  maturity, 
performance,  conformance,  and  future  needs)  in  making  the  standards  selection.  Typical 
guidelines  for  choosing  interface  standards  are: 

•  hardware  and  software  interfaces  identified; 

•  interface  standards  based  upon  open  specification  and  standards,  where 
practical; 

•  proprietary  and  unique  system  interfaces  identified; 

•  minimal  use  of  options  or  extensions  to  interface  standards; 

•  supportabihty,  upgrade,  or  technology  insertion  plans  considered  in  standards 
selection; 

•  market  analysis  of  commercial  items  or  nondevelopmental  items  interface 
standards  used; 

•  assessment  of  customers  using  the  selected  interface(s); 

•  assessment  of  supphers  providing  products  comphant  with  the  interface(s) 
selected;  and 
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•  compliance  assessment  of  interfaces  to  the  TAFIM  whenever  the  system  inter¬ 
faces  with  command,  control,  communication,  computer,  intelhgence,  sur¬ 
veillance,  and  reconnaissance  (^SR)  systems. 

28.4.2  Architecture 

An  architecture  identifies  components,  the  relationship  among  components,  and  die  rules 
for  the  architecture's  composition.  An  open  system  approach  is  based  on  an  architecture 
that  uses  open  standards  to  describe  these  relationships  and  rules.  Typical  guidelines  for 
addressing  architecture  are: 

•  Define  and  describe  a  system  architecture  that  is  traceable  to  the  Operational 
Requirements  Document  (ORD). 

•  A  preferred  architecture  is  modular,  hierarchical,  layered,  and  based  on  open 
standards  at  its  interfaces. 

•  Selection  of  an  architecture  should  be  a  cooperative  process  between  govern¬ 
ment  and  industry. 

•  Specify  key  performance  attributes  of  system  building  blocks  including  inter¬ 
nal  interface  standards  where  necessary. 

•  Where  a  new  system  is  contemplated,  consensus  among  potential  contractors 
and  their  key  suppUers  on  application  of  widely  accepted  standards  is  desir¬ 
able. 

•  Identify  aspects  of  the  program  that  might  limit  the  use  of  an  open  systems 
approach. 

•  Determine  the  level  at  which  the  architecture  will  be  defined  for  the  system. 

•  The  architecture  approach  resulting  from  a  system  engineering  process  should 
be  Unked  to  a  business  case  analysis. 

•  Decisions  about  architecture  should  be  linked  to  performance,  Ufe-cycle  cost, 
schedule,  and  risk. 

•  Identify  opportunities  for  reuse  of  hardware  and  software  configuration  items 
and  dependence  upon  interfaces. 

28.4.3  Associated  Risks 

An  open  systems  approach  should  facilitate  the  management  of  risks  associated  with  the 
use  of  commercial  items  or  nondevelopmental  items.  Although  the  open  systems  ap- 
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proach,  through  the  use  of  open  specifications  and  standards,  serves  to  mitigate  risks,  it 
also  carries  its  own  unique  risks.  The  risks  associated  with  products  implementing  open 
systems  may  be  varied;  but  potential  issues,  such  as  product  availability,  supportability, 
standards  conformance,  and  configuration  control,  may  need  to  be  addressed.  The  fol- ' 
lowing  are  guidehnes  for  consideration: 

•  Identify  the  risk(s)  to  the  program  as  a  result  of  implementing  open  systems. 

•  Determine  the  risk  mitigation  approach  for  handling  the  risk(s). 

•  Determine  which  hardware  and  software  areas  present  potential  risks  when 
using  open  systems. 

•  Determine  which  hardware  and  software  will  be  reused  and  which  impede 
open  systems. 

•  Establish  contract  incentives  to  facilitate  the  open  systems  approach. 

•  Establish  a  teaming  arrangement  that  is  eondueive  to  implementing  impartial 
interfaces. 

•  Establish  a  process  supported  by  a  "make  or  buy"  plan  for  choosing  between 
the  development  or  purchase  of  end  items  within  the  system. 

•  Assure  that  the  contract  imposes  necessary  system  interfaces  including  those 
for  legacy  systems  interoperability  and  interchangeability  and  open  system 
interfaces  for  new  technology. 

28.4.4  Supportability 

The  use  of  open  standards-based  commercial  items  or  nondevelopmental  items  brings  a 
host  of  new  support  considerations.  Baselines  will  continue  to  migrate  because  industry 
releases  new  products  in  a  shorter  time  frame  than  is  customary  in  the  traditional  DoD 
systems  acquisition  process.  With  inexpensive  product  availability  and  the  ease  of  inser¬ 
tion  that  is  faeilitated  by  the  employment  of  open  standards-based  products,  the  mainte- 
nance  approach  for  an  open  system  changes  dramatically. 

•  Support  planning  and  execution  should  consider  how  an  open  system  envi- 
ronment  would  be  accommodated. 

•  Support  drivers  (product  uniqueness,  spares,  redundancy,  graceful  degrada¬ 
tion,  fault  detection  and  isolation,  and  design  stability)  that  influence  the 
maintenance  philosophy  and  the  interdependencies  with  open  system  imple¬ 
mentation  should  be  examined. 


28-6 


•  Assess  the  change  in  maintenance  approach  via  upgrade  verses  traditional  re¬ 
pair  and  reuse. 

•  Assess  the  support  infrastructure  ability  to  accomplish  technology  insertion  in 
lieu  of  traditional  repair  and  reuse. 

•  Re-assess  the  technological  currency  of  the  products  supporting  the  system  s 
logical,  functional,  and  physical  interfaces.  Also  re-assess  the  associated 
standards  upon  which  the  products  are  based  and  develop  a  risk  mitigation  and 
technology  migration  plan  to  accommodate  system  obsolescence,  upgrade 
changes,  and  technology  enhancements. 

28.5  technology  INSERTION  DURING  THE  DEVFXOPMENT  AND 
PEOnTTCTTON  PHASES 

The  rapid  pace  of  technological  improvement  in  today’s  commercial  market  demands  that 
the  program  IPTs  (e.g.,  design/support  IPTs)  search  for  opportunities  to  enhance  the  sup- 
portability  and  reliability  characteristics  throughout  the  development  process.  As  new 
opportunities  are  brought  to  light,  the  IPTs  should  oversee  a  cost-benefit  analysis  of  each 
candidate  item  to  assist  the  PM  in  his  decision  and  timing  regarding  the  insertion.  The 
funding  of  a  technology  insertion  is  a  challenge  at  any  stage  in  the  weapons  system  de¬ 
velopment  cycle;  but  it  is  generally  simpler  in  the  development  or  production  phases, 
where  RDT&E  and  production  funds  are  available,  than  it  is  in  the  phases  subsequent  to 

production. 

28.6  POSTPRODTJCTTON  TECHNOLOGY  INSERTION 
28.6.1  Identification  of  System  O&S  Cost  Drivers 

Each  of  the  Services  has  automated  methods  in  place  to  characterize  O&S  costs.  These 
include  the  various  Service-specific  Visibility  and  Management  of  Operation  and  Support 
Cost  (VAMOSC)  implementations  as  well  as  other  systems.  However,  no  Service  is 
capturing  actual  costs  by  system.  Typically,  the  Services  capture  maintenance  rates  and 
supply  demand  rates,  compute  system  O&S  costs  using  standard  labor  hour  and  supply 
prices,  and  allocate  costs  by  system.  These  processes  are  error-prone,  subject  to  data 
losses  (such  as  lost  computer  tapes),  and  also  subject  to  erroneous  input  factors. 

Despite  such  limitations,  existing  automated  cost  systems  are  good  enough  to  support 
system-specific  O&S  cost  reduction  efforts.  The  reason  is  that,  for  purposes  of  deter¬ 
mining  O&S-related  opportunities  for  technology  insertion  (e.g.,  reliability  improve¬ 
ment),  the  methods  are  generally  adequate.  Although  the  systems  cannot  accurately  de¬ 
termine  absolute  costs,  they  can  establish  relative  costs;  and  this  capabiUty  is  what  is 
needed  to  identify,  in  turn,  the  cost  drivers.  It  is  the  cost  drivers  that  are  pnme  targets  of 

opportunity. 
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28.6.2  Prerequisites  for  Technology  Insertion  to  Reduce  O&S  Costs 
Three  fundamental  factors  must  be  in  place  to  use  technology  to  reduce  O&S  costs: 

•  The  technology  itself  must  be  available.  It  must  be  developed  and  proven  suf¬ 
ficiently  to  be  adapted  to  specific  systems,  and  it  must  provide  a  cost  reduc¬ 
tion  opportunity.  Application  could  be  either  to  the  weapon  support  infra¬ 
structure  or  to  the  embedded  subsystem  or  component  of  a  system  itself. 

•  There  must  be  sufficient  resolve  to  use  the  technology  and  dedicate  resources 
to  that  end.  Typically  a  technology  insertion  for  purposes  of  cost  reduction 
involves  an  initial  expense  justified  by  a  cost-benefit  analysis  that  demon¬ 
strates  a  cost  reduction  in  the  long  run.  To  qualify,  the  Services  generally  re¬ 
quire  the  cost-benefit  ratio  to  exceed  a  specified  threshold  value  within  a  pre¬ 
scribed  time  period. 

•  There  must  be  opportunity  to  apply  technology.  The  life  cycle  of  a  weapons 
system  presents  three  basic  windows  of  opportunity:  during  the  development 
phase  of  system  acquisition,  during  a  major  modification  of  the  weapons  sys¬ 
tem,  or  during  insertion  in  in-service  weapons  systems  (the  principle  focus  of 
this  chapter). 

Funding  has  been  the  sticking  point  in  the  past  for  cost-saving  technology  insertion. 
Candidate  cost-saving  projects  tend  to  compete  for  limited  funds  with  numerous  other 
programs/modifications  that  promise  increased  operational  capability.  Repeatedly  the 
cost-saving  candidates  are  ranked  too  low  to  be  funded,  particularly  in  the  postproduction 
phase.  However,  wi*  the  advent  of  the  Cost  as  an  Independent  Variable  (CAJV)  direc¬ 
tion,  hfe-cycle  cost  is  a  driving  program  management  consideration;  and  the  PM  and  the 
entire  acquisition  system  are  more  closely  attuned  to  cost-saving  opportunities.  In  addi¬ 
tion,  concerted  efforts  are  underway  at  OSD  and  Service  levels  to  develop  funding  strate¬ 
gies  that  will  assist  the  PM  s  efforts  to  insert  new  technology  and,  thereby,  enhance  reli¬ 
ability  or  otherwise  reduce  life  cycle  cost. 


28.6.3  The  Defense  Working  Capital  Fund  (DWCF) 

The  DWCF  (formerly  known  as  the  Defense  Business  Operating  Fund  is  a  potential 
source  for  financing  cost-saving  technology  insertion  candidates.  A  description  of  the 
“DWCF  is  presented  in  the  following  paragraphs.  The  reference  source  is  the  “DWCF 
Handbook,  CALIBRE  Systems,  Incorporated,  Falls  Church,  Virginia,  and  the  Office  of 
the  Under  Secretary  of  Defense  (Comptroller),  Washington,  DC,  1995. 

As  a  revolving-fund  financial  structure,  the  DWCF  builds  on  revolving-fund  principles, 
which  were  previously  used  for  industrial  and  commercial-type  operations.  The  DWCF 
consists  of  multiple  divisions  identified  by  Component  and  by  business  area.  Within 
these  business  areas,  there  are  support  organizations  (providers)  operating  like  commer- 
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dal  businesses  by  selling  goods  and  services  to  DoD’s  operating  forces  and  other  busi¬ 
ness  areas  (customers). 

Customer  orders  (funded  requests  for  goods  and  services)  provide  the  budgetary  re¬ 
sources  to  finance  defense  business  operations.  Customers  fund  their  requests  primarily 
with  appropriated  resources,  e.g.,  operation  and  maintenance;  procurement;  and  research, 
development,  test  and  evaluation.  Income  (or  budgetary  resources),  which  is  derived^ 
from  the  sale  of  goods  and  services,  is  then  used  to  finance  the  DWCF  business  areas’ 
continuing  operations  without  fiscal  year  limitations.  Unhke  profit-oriented  commercial 
businesses,  DWCF  businesses  strive  to  break  even  in  prices  charged  to  customers.  Reve¬ 
nue  from  customers  sustains  the  full  cost  and  the  continuous  cycle  of  DWCF  business 
operations. 

The  basic  tenet  of  the  DWCF  financial  structure  is  to  create  a  customer-provider  relation¬ 
ship  between  military  operating  forces  and  support  organizations. 

•  Customers  of  the  DWCF  business  area  providers  include  any  DoD  command, 
organization,  non-DoD  Federal  Government  Agencies,  and  other  U.S.  and 
foreign  agencies  and  commercial  enterprises  when  authorized  by  DoD. 

•  Providers  in  the  DWCF  customer/provider  relationship  are  the  business  areas 
and  related  support  organizations  that  are  responsible  for  providing  goods  and 
services  to  the  operating  forces  and  that  are  financed  through  the  DWCF. 

The  customer/provider  relationship  is  fundamental  to  the  DWCF  financial  structure.  The 
relationship  has  significantly  increased  the  customer’s  responsibility  for  properly  deter¬ 
mining  support  requirements  and  the  level  of  performance  required  from  DWCF  financed 
support  organizations.  The  result  of  the  customer/provider  relationship  is  a  meaningful 
linkage  between  military  mission  operations  and  the  cost  to  support  those  operations. 

This  Unkage  is  a  major  feature  of  the  DWCF’s  control  process.  The  inclusion  of  previ¬ 
ously  directly  financed  areas  in  the  DWCF  is  causing  the  DWCF  business  area  operations 
to  be  financially  sized  (in  both  budget  and  implementation).  This  “sizing  is  based  on 
their  customers’  requirements  and  appropriated  resources  available  for  DWCF  goods  and 
services.  In  other  words,  the  resources  required  by  the  DWCF  business  area  organiza¬ 
tions  to  continue  operations  vary  directly  with  their  customers’  needs  for  their  goods  and 
services.  As  the  volume  of  customer  requirements  deeline,  the  relative  financing  of  a 
supporting  DWCF  business  area  will,  too.  The  significance  of  this  linkage  makes  it  es¬ 
sential  for  customers  and  providers,  alike,  to  understand  the  nature  of  the  DWCF  finan¬ 
cial  processes  and  the  potential  impact  they  can  have  on  military  readiness. 

In  summary,  the  DWCF  financial  structure  and  management  proeess  focus  on  totol  cost 
visibility  and  full  cost  recovery  for  DoD’s  support  functions.  The  DWCF  financial 
structure  provides  DoD  managers  with  improved  financial  management  tools  and  facili¬ 
tates  the  reduction  of  DoD  support  costs  through  better  business  practices.  The  use  of  the 
DWCF  finaneial  structure  is  intended  to: 
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•  foster  a  business-like  customer/provider  approach  that  enables  the  customer  to 
make  economical  buying  decisions  and  encourage  the  provider  to  become 
more  cost  conscious; 

•  identify  the  full  costs  of  support,  measure  performance  on  the  basis  of  cost/ 
output  goals,  and  foster  efficiency  and  productivity  improvements; 


•  provide  timely  and  accurate  information  to  decision  makers  at  all  levels  to  en¬ 
hance  the  decision-making  process;  and 

•  more  closely  relate  the  support  infrastructure  with  the  force  structure. 

28.6.4  Alternative  Funding  Sources 

Generally,  a  potential  candidate  for  cost-saving  technology  insertion  on  in-service  sys¬ 
tems  (infrastructure  or  embedded)  must  be  able  to  project  a  payback  within  five  years  to 
defray  the  front-end  startup  costs  and  further  attain  savings  in  the  out  years  during  the 
remainder  of  the  service  life.  There  are  three  general  ways  to  finance  the  front-end  costs 
of  a  cost-saving  technology  insertion  opportunity;  these  three  ways  utihze:  (1)  appropri¬ 
ated  funds,  (2)  the  Defense  Working  Capital  Fund  (DWCF),  or  (3)  DWCF  funds  com¬ 
bined  with  appropriated  start-up  funds. 

Appropriated  Funds.  Either  the  military  Services  or  OSD  could  budget  appro- 
pnated  funds.  Historically,  Service  attempts  to  budget  funds  for  cost-reduction  have  not 

worked  well.  Cost-reduction  projects  typically  rank  below  the  prioritization  cut-off  line 
and,  thus,  are  not  funded. 


Rnancing.  A  potentially  attractive  alternative  to  appropriated  funding  is 

DWCF  funding.  Three  DWCF  approaches  should  be  considered  in  the  following  circum- 
stances  I 


1)  The  funds  needed  to  finance  cost-reduction  modifications  could  simply  be  in¬ 
cluded  in  the  DWCF  operations  budgets.  This  approach  has  the  advantage  of  re- 
covenng  the  investment  immediately.  However,  it  also  affects  user  prices  in  the 
year  of  investment,  forcing  them  to  pay  up  front  for  an  investment  that  will  pro¬ 
duce  savings  later.  Users  understandably  are  not  enthusiastic  about  this  approach. 

2)  It  IS  possible  to  request  direct  appropriations  for  insertion  into  the  DWCF  compo¬ 
nents  (Army,  Navy,  and  Air  Force).  The  problems  with  this  approach  are  that  the 
investment  is  not  necessarily  recovered  (there  is  no  obvious  mechanism  to  do  so) 
and  that  the  approach  amounts  to  a  pass-through  of  appropriated  funds.  Hence  it 
adds  little  or  no  value  while  placing  DWCF  administrative  procedures  on  top  of 
appropriated  procedures. 
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3)  By  using  the  DWCF  capital  budgets,  the  investment  could  be  recovered.  Addi¬ 
tionally,  from  the  operational  user’s  point  of  view,  amortizing  the  investment  over 
the  period  of  expected  benefits  would  match  the  cost  and  benefit  streams  in  time. 

It  is  this  approach  that  is  recommended  in  most  cases. 

To  implement  the  DWCF  capital  budget  approach,  it  is  still  necessary  to  provide  up-front 
funding  until  the  program  is  self-financing.  This  funding  could  come  form  two  sources: 
(1)  DWCF  cash  can  be  used,  assuming  cash  is  available;  and  (2)  an  initial  appropriated 
input  can  be  used.  The  latter  is  the  case  for  Program  Budget  Decision  (PBD)  Number 
714  of  29  January  1996.  A  copy  of  that  PBD  is  attached  at  the  end  of  this  chapter.  A 
substantial  investment  will  be  needed  for  some  time  until  the  program  becomes  self¬ 
financing.  The  investment  required  depends  on  the  magnitude  of  benefits  desired.  The 
period  until  the  program  becomes  self-financing  will  depend  on  both  the  actual  rate  of 
return  and  the  amortization  schedule. 

28.6.5  Service  Potential  for  Technology  Insertion 

In  a  recent  study  conducted  by  the  Logistics  Management  Institute  (LMI),  each  Service 
was  contacted  to  propose  promising  candidate  components  or  subsystems  for  which  the 
technology  exists  to  allow  substitution  of  technically  superior  items  to  improve  overall 
system  reliability  and  maintainability.  A  significant  number  of  candidates  were  identi¬ 
fied.  For  each  candidate,  the  required  initial  investment  was  calculated,  and  then  the  po¬ 
tential  return  on  investment  (ROI)  was  calculated  assuming  a  service  hfe  of  10  years  or 
more  following  the  modification,  at  which  time  the  savings  would  theoretically  end. 

(ROI  is  the  savings  in  operating  costs  over  a  defined  period  divided  by  the  front-end  in¬ 
vestment.)  The  study  concluded  that  for  a  sustained  program,  an  ROI  of  9:1  could  be 
achieved,  with  the  greatest  potential  return  available  from  those  items  that  focus  on  im¬ 
proved  reliabihty  (as  opposed  to  maintainabihty). 

The  Army  and  the  Navy  depend  on  industry  sources  to  bring  forth  cost-saving  ECPs  at 
their  own  expense.  As  a  result,  candidate  items  generally  have  been  limited  to  those  cases 
where  the  benefits  are  so  dramatic  that  the  initiators  have  high  confidence  that  the  ECP 
will  be  approved.  The  result  has  been  a  paucity  of  Army  and  Navy  candidate  projects  in 
the  past.  Candidate  Army  projects  that  do  emerge  are  produced,  for  example,  by  the 
Army  Tank  Automotive  and  Armaments  Command  (TACOM),  which  is  under  a  Tech¬ 
nology  Insertion-Operation  and  Support  Cost  Reduction  (TI-OSCR)  program  and  is 
funded  under  DWCF.  The  Navy  considers  similar  projects  under  the  BOSS-III  program, 
whieh  is  project-by-project  funded  under  DWCF.  The  Air  Force  PRAM  program  is,  also, 
typically  accomplished  with  DWCF  funding  after  the  engineering  development. 
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28.6.6  Examples  of  Postproduction  Technology  Insertion 

The  Air  Force  is  currently  in  the  lead  in  this  regard.  They  have  a  Technology  Transition 
Office  and  a  budget  line  item  (RDT&E)  to  perform  the  front-end  engineering  to  identify 
candidate  projects  and  develop  appropriate  engineering  change  proposals  (ECPs),  either 
in-house  or  under  contract.  They  have  developed  at  least  19  specific  subprojects  with 
funding  of  about  $220  million  annually  (RDT&E  funds).  One  of  these,  the  Producibility, 
Rehability,  and  Maintainability  (PRAM)  project,  is  level-of-effort  funded  at  $20  million ' 
annually.  Overall,  PRAM  has  produced  a  return  on  engineering  investment  of  about  5:1. 

Cost-reduction  opportunities  exist  through  insertion  of  technology  into  the  infrastructure 
as  well  as  into  the  weapons  systems  themselves.  An  example  involving  the  support  infra¬ 
structure  is  the  replacement  of  standard  hard-copy  technical  manuals  with  Interactive 
Electronic  Technical  Manuals  (lETMs).  A  demonstration  test,  which  the  Air  Force  ran 
on  the  F- 16  aircraft,  documented  a  reduction  in  diagnostic  time  of  40  percent.  In  addi¬ 
tion,  the  test  demonstrated  a  large  increase  in  the  diagnostic  success  rate,  which  ap¬ 
proached  100  percent.  Both  factors  are  important  to  cost.  But  the  diagnostic  success  rate 
is  particularly  important  because  it  influences  retest-OK  rates;  and  they,  in  turn,  influence 
spares  pipeline  requirements. 

An  embedded  cost-reduction  opportunity  was  pursued  in  the  case  of  the  C-17  aircraft 
during  the  development  cycle.  The  TF33  engine  powered  the  C-141  predecessor  aircraft. 
The  C-1 17  engine  developed  for  the  C-17  aircraft  has  a  fuel  consumption  rate  of  ap¬ 
proximately  60  percent  of  the  TF33  engine,  and  fuel  costs  are  a  major  part  of  the  cost-of- 
ownersWp  of  an  aircraft.  Thus,  the  cost  avoidance  over  the  30-year  or  greater  life  cycle 
of  Ae  aircraft  wiU  be  very  great.  In  addition,  the  C-1 17  engine  is  roughly  five  times  as 
rehable  as  the  TF33  due,  in  large  part,  to  a  set  of  demanding  reliability  and  maintainabil¬ 
ity  performance  requirements  laid  down  in  the  Operational  Requirements  Document 
(ORD)  at  the  onset  of  the  system  development. 

Another  cost-reduction  opportunity  was  accomphshed  on  the  in-service  F-14  aircraft 
fleet.  The  original  mechamcal  gyroscopes  on  the  aircraft  were  replaced  by  a  new- 
technology,  the  Embedded  GPS  Inertial  (EGI)  system.  The  new  inertial  system  is  dem¬ 
onstrating  a  100-fold  improvement  in  reliability  -  from  40  hours  MTBF  for  the  mechani¬ 
cal  gyro  to  4,500  hours  for  the  EGI  system. 

The  Army  s  5-ton  trucks  are  6-wheel-dnve  vehicles.  They  were  designed  with  universal 
joints  on  the  front  axles.  Due  to  the  geometry  involved,  U-joints  cause  a  sinusoidal 
variation  in  tire  rotation  speed  when  the  vehicle  is  turning.  This  design  causes  acceler¬ 
ated  tire  wear  during  turns.  The  automobile  industry  has  designed  front-wheel-drive  cars 
with  constant  velocity  (CV)  joints  to  overcome  this  effect.  The  Tank  and  Automotive 
Command  has  introduced  a  program  to  replace  both  U-joints  with  form-and  fit- 
compatible  CV  joints  whenever  one  of  the  U-joints  fails.  The  savings  in  this  case  are  in 
longer  tire  Ufe.  The  program  achieves  rapid  savings,  with  the  break-even  point  occurring 
in  about  two  years. 


28-12 


28.7  MODIFICATION  MANAGEMENT 


The  starting  point  in  change  preparation  is  recognition  of  a  deficiency  and  the  decision  to 
employ  a  design  solution.  The  request  to  change  production,  and  possibly  retrofit  fielded 
equipment,  may  be  originated  by  the  government  or  the  contractor.  One  approach  is 
preparation  of  an  Engineering  Change  Proposal  (ECP).  Numerous  contractor  and  gov¬ 
ernment  actions  are  involved  in  the  process  of  responding  to  a  deficiency  with  an  ECP. 

An  example  of  the  actions  involved  from  the  preparation  of  an  ECP  by  a  contractor  and 
the  subsequent  change  implementation  by  the  government  is  shown  in  Figure  28-1. 

The  Logistics  Managers  (LMs)  must  be  actively  involved  in: 

•  determining  the  impact  of  the  ECP  on  each  logistics  element, 

•  developing  requirements  and  schedules  for  required  changes  to  affected  logis¬ 
tics  elements; 

•  participating  in  engineering  review  board  and  change  review  board  meetings; 

•  ensuring  that  associated  changes  for  related  support  equipment  and  training 
devices  are  available  for  concurrent  review  and  approval; 

•  ensuring  lead  times  for  changes  to  logistics  elements  are  compatible  with  the 
planned  implementation  of  the  ECP  on  the  production  hne;  and 

•  ensuring  that  changes  to  logistics  elements  are  funded. 

28.7.1  Change  Implementation 

After  government  approval,  the  contractor  initiates  action  to  finahze  the  change  for  pro¬ 
duction  and/or  retrofit  concurrently  to  modify  the  affected  logistics  elements.  The  gov¬ 
ernment  accepts  the  modified  systems.  The  government  LM  is  normally  responsible  for 
the  appUcation  of  retrofit  kits  and  must  assure  that  the  required  changes  to  the  logistics 
support  of  fielded  systems  are  applied  or  are  available  concurrently  with  die  application 
of  retrofit  kits  to  the  systems.  Grouping  retrofit  kits  into  block  modifications  and  apply¬ 
ing  them  to  complete  production  lots  can  facihtate  this  latter  requirement. 

28.7.2  Management  Information  System 

A  management  information  system  (to  include  logistics  elements)  is  an  essential  compo¬ 
nent  of  configuration  status  accounting.  It  is  employed  to  manage  changes  of  logistics 
resources  and  to  maintain  concurrent  compatibihty  with  changes  to  the  system. 
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Figure  28-1:  One  Variation  of  ECP  Preparation  and  Implementation 

by  a  System  Contractor 
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ATTACHMENT  A  TO  CHAPTER  28 


A  CLOSE  FACSIMILE  TO  PROGRAM  BUDGET  DECISION 

NUMBER  714, 

FISCAL  YEAR  1997 


Attachment  A  is  presented  for  teaching  purposes  only. 
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FOR  OFFICIAL  USE  ONLY 

PROGRAM  BUDGET  DECTSTON 


SUBJECT :  Depot  Maintenance  Reliability  Program 


POD  COMPONENTS:  Army,  Navy,  Air  Force 


Service  Estimate 
OA,  $  Millions 
Civilian  End  Strength 
Civilian  Fees 

Alternative  Estimate 
OA,  $  Millions 
Customer  TOA 


FY  1996 


SUMMARY  OF  EVALUATION:  The  decision  document: 

•  Establishes  a  program  within  the  Services’  DBOF  Depot 
Maintenance  and  Supply  Business  Areas  to  finance 
investments  in  weapon  system  reliability  (OA). 

•  Increases  O&M,  Defense-Wide  in  FY  1997  to 
initially  finance  this  program  (TOA). 

•  Provides  for  projected  savings  in  the  customer  accounts 
in  the  outyears  for  these  rehability  enhancements: 

$-4.5  million  in  FY  2000,  $-1 17.0  million  in  FY  2001,  and 
approximately  $-2.0  billion  by  FY  2010  (TOA). 

•  Amortizes  the  cost  of  these  investments  on  a  straight  line 
method,  within  customer  rates  in  the  outyears  (TOA). 

•  Provides  for  the  savings  generated  by  this  Depot  Maint¬ 
enance  Reliability  Program  to  be  used  for  new  procure¬ 
ment  force  modernization  programs  starting  in  FY  2000 


THE  DEPUTY  SECDEF  APPROVF.n 

DECISION  THE  ALTERNATE  ESTIMATE  DATE 

FOR  OFFICIAL  USE  ONLY 


.714 


FY  1997 


+90.0 

+90.0 


+90.0 


+90.0 


JAN  29  1996 
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FOR  OFHCIAL  USE  ONLY 

PROGRAM  BUDGET  DECISION  No.  lu 


DETAIL  OF  EVALUATION: 

Reliability,  Maintainability,  and  Supportability  (RM&S)  depot  maintenance  modifica¬ 
tions  to  weapon  systems  can  reduce  their  life  cycle  costs.  Some  studies  have  indicated 
that  such  investments  can  generate  rates  of  return  in  excess  of  9: 1  over  the  life  of  the 
weapon  system..  The  Military  Departments  currently  finance  some  aspects  of  these  reli- 
abihty  improvements  in  their  Defense  Business  Operations  Fund  (DBOF)  programs. 
However,  a  more  concentrated  effort  to  identify  and  finance  RM&S  investments  with 
high  paybacks  that  are  not  currently  being  financed  is  justified  because  the  longer-term 
results  wiU  be  lower  cost  and  more  reliable  weapon  systems. 


BUILD-IN  RELIABILITY: 

It  has  been  recognized  for  many  years  that  within  the  procurement  process  attention  must 
be  paid  to  the  overall  life  cycle  cost  of  a  system,  not  just  its  initial  purchase  and  deploy¬ 
ment  costs.  Consequently,  concerted  efforts  have  been  made  to  build-in  increased  reli- 
abihty  and  maintainability  in  new  systems  and  major  end  efforts  and  have  institutional¬ 
ized  these  concepts  into  new  system  procurements. 

Further,  under  the  Centers  of  Excellence  approach  within  the  Services’  organic  depots 
most  major  end  items  and  weapon  systems  have  assigned  cognizant  engineering  support 
offices  who  provide  a  range  of  support  for  these  systems.  Support  provided  includes: 
assessing  quality  deficiencies  reports  provided  by  customers  to  identify  components  or 
aspects  of  systems  that  have  high  failure  rates  or  require  excessive  maintenance,  review¬ 
ing  maintenance  processes  and  methods  to  find  more  efficient  and  less  costly  means  of 
maintaining  systems,  maintaining  historical  and  engineered  industrial  standards  on  sys¬ 
tems,  and  working  with  Weapon  System  Program  Managers  to  identify  both  new  tech¬ 
nology  that  can  be  embedded  in  new  systems  and  upgrades  or  modifications  that  can  be 
procured  and  installed  in  existing  systems  to  improve  rehability. 

However,  the  amount  of  funding  targeted  for  reliability  upgrades  of  existing  weapon 
systems  and  major  end  items  has  been  small,  even  though  weapon  systems  are  staying  in 
the  active  inventory  for  longer  periods  and  the  number  of  new  systems  being  procured 
has  dropped  significantly  in  recent  years. 
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FOR  OFFICIAL  USE  ONLY 

PROGRAM  BUDGET  DRCTSTON  no  7i4 


AVAILABLE  TECHNOLOGY; 

There  are  numerous  examples  of  existing  technology,  available  through  current  defense 
contractors,  that  have  been  demonstrated  to  improve  the  rehabihty  or  maintainabihty  of 
numerous  systems.  Consequently,  there  is  considerable  potential  for  selecting  proven 
technology  for  phased  insertion  into  existing  systems  that  are  planned  to  be  retained  in 
the  active  inventory.  These  will  either  reduce  failure  rates  of  system  components,  in¬ 
crease  the  mean  time  between  required  depot  maintenance  on  the  system,  or  make  the 
maintenance  process  itself  more  efficient  and  less  costly.  These  investments  will  reduce 
the  overall  cost  of  ownership  of  these  systems  and  improve  battlefield  performance  by 
enhancing  Mission  Capable  Rates. 

DEPOT  MAINTENANCE  RELIABILITY  PROGRAM: 

The  alternative  establishes  a  program  through  the  DBOF  Depot  Maintenance  Business 
Area  cognizant  engineering  support  offices  to  finance  selected  technology  insertion  - 
modification  projects  to  enhance  the  reliabihty  of  weapon  systems  and  to  reduce  the  cost 
of  ownership. 

Investments  will  be  identified  in  a  new,  separate  capital  purchase  category  called  RM&S 
Mods  beginning  in  FY  1997.  DFAS  wUl  establish  a  capability  to  separately  track  obhga- 
tions  and  associated  outlays  by  program  year  for  these  investments,  as  is  currently  re¬ 
quired  for  equipment,  minor  construction,  software,  and  non-ADPE  DBOF  capital  pur¬ 
chase  equipment  investments. 

Initial  funding  of  $90  milhon  will  be  provided  in  O&M,  Defense-Wide,  the  Defense  Lo¬ 
gistics  Agency,  who  will  provide  funded,  reimbursable  project  orders  to  the  Depots  as 
listed  in  the  table  below.  The  project  orders  will  include  the  acquisition  cost  of  compo¬ 
nents  or  parts  needed  to  be  purchased  and  the  costs  associated  with  the  installation  of  the 
item  by  the  Depot  after  procurement,  on  a  full  funding  basis  for  each  approved  project. 
DLA  will,  within  the  totals  provided  for  each  Mihtary  Department,  fund  the  projects  as 
provided  in  the  final  Component  approved  project  hsts,  that  have  been  authorized  for  in¬ 
clusion  in  the  respective  DBOF  Depot  Business  Area  Capital  budgets. 

Outyear  purchases  will  be  financed,  as  with  all  the  capital  purchase  program,  using  con- 
ftact  authority.  Given  the  time  required  to  set  up  the  program,  to  estabhsh  guidelines,  to 
identify  technology  projects,  and  to  complete  the  acquisition  process,  no  disbursements 
(cash  outlays)  in  FY  1997  are  anticipated.  Modification  kit  dehveries  and  installations 
from  FY  1997  investments  are  anticipated  in  FY  1999.  Management  of  the  program  wiU 
be  conducted  through  existing  staff  organizations  within  the  depots. 
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OUSD(A&T),  in  conjunction  with  OUSD(C),  will  develop  and  issue  supplementary 
guide-lines  and  instructions  for  the  Components  on  the  related  logistics  and  financial 
policy  considerations  for  this  program.  The  DUSD(Logistics)  will  identify  procedures 
for  identification  of  candidate  technology  insertion  projects  and  distribute  information  on 
proven,  high-payback  modification  programs.  Additionally,  the  Military  Departments 
will  be  required  to  provide  present  value,  economic  cost-benefit  analysis  studies  to  sup¬ 
port  requested  projects,  as  required  by  the  DBOF  policies  contained  in  the  DoD  Financial 
Management  Regulation. 

Current  engineering  staffs  within  each  of  the  Service  Depot  Maintenance  organizations 
are  expected  to  locally  manage  the  RM&S  Mod  program.  The  candidate  Depot  project 
lists  must  be  prepared  in  conjunction  with,  and  with  the  coordination  of,  the  appropriate 
Weapon  System  Program  Management  offices  in  the  Services.  For  FY  1997,  the  Com¬ 
ponents  will  provide  the  DUSD(Logistics)  and  the  OUSD(C)  a  list  of  the  specific  projects 
that  are  proposed  to  be  financed  in  FY  1997.  Those  projects  meeting  the  general  criteria 
established  for  the  program  and  demonstrating  an  acceptable  financial  pay  back  will  be 
approved  for  inclusion  in  the  budget.  The  approved  project  lists  and  the  appropriate 
DBOF  budget  justification  exhibits  are  to  be  provided  by  the  Services  to  the  OUSD(C) 
and  DLA  by  February  10,  1996,  to  provide  sufficient  time  for  the  Components  to  include 
the  projects  in  the  individual  DBOF  Capital  Purchase  budgets  that  will  be  submitted  to 
Congress  in  the  President’s  budget. 

Acquisition  support  for  the  Depot  RM&S  program  will  be  provided  by  Inventory  Control 
Points  (ICPs).  In  FY  1997,  after  receipt  of  a  funded  order  for  the  RM&S  program  the 
Depots  will  provide  purchase  orders  to  the  appropriate  ICP  responsible  for  acquisition  of 
any  parts,  components,  or  sub-systems  required  for  the  approved  project.  Depots  will 
retain  funding  for  the  subsequent  installation  of  the  items.  After  FY  1997,  Depots  will 
continue  to  coordinate  all  proposed  projects  with  cognizant  Service  Weapon  System  Pro¬ 
gram  Offices  and  to  acquire  all  required  components,  parts,  or  sub-systems  through  the 
appropriate  ICP,  in  accordance  with  DBOF  Capital  Budget  policies  and  procedures. 

The  Components’  FY  1997  Procurement  appropriation  budgets  should  be  adjusted  to 
eliminate  any  current  fully  financed  RM&S  Mods  that  were  to  have  been  initiated  in  FY 
1997.  Components  may  propose  realignment  of  any  such  projects  into  the  DBOF  RM&S 
Mods  program.  Approved  realignments  will  be  included  in  PBD  426. 

Since  the  modifications  purchased  become  a  part  of  the  weapon  system  or  end  item,  which 
does  not  belong  to  the  DBOF  and  cannot  be  depreciated,  DBOF  financing  will  be  reimbursed 
by  amortizing  the  cost  of  the  investment  within  customer  rates.  The  amortization  will  be  on  a 
straight-line  10-year  basis  consistent  with  other  equipment  investments  within  the  DBOF. 
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This  customer  surcharge  will  provide  the  necessary  cash  to  finance  these  types  of  invest¬ 
ments  and  to  reimburse  DBOF.  The  alternative  provides  for  initial  annual  investments  of 
$90  million.  Further,  the  alternative  provides  for  this  program  to  be  assessed  again  in  the 
FY  1998  Program  and  Budget  Review,  to  establish  the  future  size  and  scope  of  this  ini¬ 
tiative  in  relation  to  other  DoD  and  Component  funding  priorities. 


Program  savings,  assumed  to  achieve  an  average  4.5:1  return  on  investment  over  10 
years,  will  more  than  offset  cash  requirements  after  the  program  becomes  fully  func¬ 
tional.  The  alternative  provides  for  initial  funding,  additional  capital  purchase  authority 
(OA),  amortization,  cash  outlays,  and  projected  savings  as  follows: 


(OA,  $ 

in  Millions) 

FY  1996 

FY  1997 

DBOF  Business  Area 

Department  of  the  Army,  Depot  Maintenance  Other 

+24.8 

Department  of  the  Navy,  Depots/Shipyards 

_ 

+35.7 

Department  of  the  Air  Force,  Depot  Maintenance 

+29.5 

Total 

- 

+90.0 

O&M,  Defense- Wide,  DLA  (TOA) 

. 

+90.0 

AMORTIZATION  TABLES 
(Dollars  in  Millions) 

(contributed  to  sinking  fund  through  FY  01)  AMORTIZATION 


FY98 

FY99 

FYOO 

FY01 

Amortization 

90  in  FY97 

9 

9 

9 

9 

90  in  FY98 

9 

9 

9 

90  in  FY99 

- 

9 

9 

90  in  FYOO 

. 

9 

90  in  FY01 

_ 

Total 

9 

18 

27 

36 

FY98 

FY99 

FYOO 

FY01 

Cash  Outlay 

90  in  FY97 

. 

_ 

90  in  FY98 

- 

45 

45 

90  in  FY99 

- 

45 

45 

90  in  FYOO 

. 

45 

90  in  FY01 

Total 

- 

~45 

~90 

“90 

FOR  OFFICIAL  USE  ONLY 

28-20 


FOR  OFRCIAL  USE  ONLY 

PROGRAM  BUDGET  DECISION  no.714 


FY98 

FY99 

FYOO 

FY01 

Savings  * 

90  in  FY97 

. 

-40.5 

-81.0 

-121.5 

90  in  FY98 

- 

- 

-40.5 

-81.0 

90  in  FY99 

- 

- 

- 

-40.5 

90  in  FYOO 

- 

- 

- 

- 

90  in  FY01 

. 

- 

- 

- 

Total 

- 

-40.5 

-121.5 

-243.0 

*4.5:1  overlOyears 

FY98 

FY99 

FYOO 

FY01 

Cost  (less  approp.) 

- 

+45.0 

+90.0 

+90.0 

Savings 

-40.5 

-121.5 

-243.0 

Amortization 

+9 

+18.0 

+27.0 

+36.0 

Surcharge  (funded  by  customers) 

Net  Savings 

- 

+22.5 

- 

- 

+9 

+22.5 

-4.5 

-117.0 

As  identified  above,  the  investment  is  more  than  offset  by  the  savings  in  the  cost  of  own¬ 
ership.  These  savings  will  be  available  to  finance  new  procurement  force  modernization 
efforts  after  the  annual  savings  begin  to  exceed  the  cumulative  costs  in  FY  2000. 


SUMMARY  OF  ADJUSTMENTS: 


Alternative 

Department  of  the  Army,  Depot  Maintenance  Other 
Department  of  the  Navy,  Depots/Shipyards* 
Department  of  the  Air  Force,  Depot  Maintenance 
Total 


(OA,  $  in  Millions) 
FY  1996  FY  1997 


+24.8 

+35.7 

+29.5 

+90.0 


•  OA  in  Department  of  the  Navy  to  be  distributed  by  business  area  based  on  final  approved  proj¬ 
ect  lists. 


O&M,  Defense-Wide,  DLA  (TOA) 


+90.0 


OUTYEARS: 

FY98 

O&M,  Army 

+2.5 

O&M,  Navy 

+3.2 

O&M,  Marine  Corps 

+0.4 

O&M,  Air  Force 

+2.9 

Total 

+9.0 

(TOA, 

FY99 

$  in  Millions) 

FYOO 

FY01 

+6.2 

-1.2 

-32.3 

+8.0 

-1.6 

-41.8 

+0.9 

-0.2 

-4.7 

+7.4 

-1.5 

-38.2 

+22.5 

-4.5 

-117.0 
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29 

DISPOSAL,  RECYCLING, 
AND  DEMILITARIZATION 


“The  significant  problems  we  face  cannot  be  solved  at  the  same  level  of 
thinking  we  were  at  when  we  created  them.  ” 

Albert  Einstein 


29.1  INTRODUCTION 

The  subject  of  this  chapter  is  con^lex  and  evolving.  It  is  an  area  in  which  the  Program 
Manager  (PM)  and  the  Program  Management  Office  (PMO)  staff  have  obligations  speci¬ 
fied  in  various  laws,  executive  orders,  treaties,  agreements,  and  a  multitude  of  DoD  and 
other  agency  regulations  and  administrative  directives.  This  chapter  is  the  briefest  of 
overviews  of  DoD  systems  life-cycle  planning  in  the  areas  of  disposal,  recycling,  and  de¬ 
militarization.  The  references  offered  at  the  end  of  the  chapter  should  further  expand  the 
reader’s  abilities  to  meet  PM  responsibilities  with  reference  to  pollution-prevention  activities. 

29.2  STRUCTURE 

In  an  effort  to  provide  some  structure  to  this  subject,  which  broadly  falls  in  the  area  of  lo¬ 
gistics,  some  text  (abbreviated)  and  organization  is  taken  from  the  Materiel  Developer's 
Guide  for  Pollution  Prevention,  Army  Acquisition  Pollution  Prevention  Support  Office, 
Second  Edition,  1994,  and  used  in  the  following  text. 

29.3  DEMILITARIZATION 

DoD  5(XX).2-R,  paragraph  1.4.6  (Demilitarization  and  Disposal),  states;  “At  the  end  of  its 
useful  life,  a  system  must  be  demilitarized  and  disposed.  During  demilitarization  and  dis¬ 
posal,  the  PM  shall  ensure  materiel  determined  to  require  demilitarization  is  controlled  and 
shall  ensure  disposal  is  carried  out  in  a  way  that  minimizes  DoD's  liability  due  to  environ¬ 
mental,  safety,  security,  and  health  issues.”  Paragraph  4.3.7  (Environment,  Safety  and 
Health)  states,  in  part:  “Environmental,  safety,  and  health  (ESH)  analyses  shall  be  con¬ 
ducted,  as  described  below,  to  integrate  ESH  issues  into  the  systems  engineering  process 
and  to  support  development  of  the  Programmatic  ESH  Evaluation....” 

Decisions  the  PM  makes  during  the  acquisition  process  will  influence  the  environmental 
impact  of  demilitarization  procedures.  As  has  been  demonstrated  by  chemical  munitions 
demilitarization  programs,  the  environmental  issues  associated  with  demilitarization  of  a 
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system  can  be  more  significant  than  those  created  during  all  previous  life-cycle  phases. 
Effective  planning  during  Phases  I  and  II  can  minimize  hazardous  waste  generation  during 
demilitarization.  As  is  the  case  throughout  the  life  cycle,  all  demilitarization  planning 
should  reflect  good  business  practices.  PMs  are  encouraged  to  select  a  demilitarization 
approach  that  minimizes  program  costs  while  simultaneously  creating  as  few  adverse  envi¬ 
ronmental  impacts  as  possible. 

The  purpose  of  this  discussion  is  to  provide  the  PM  with  information  about  preferred  de¬ 
militarization  approaches  that  are  also  effective  acquisition  decisions.  If  an  acquisition 
program  is  just  being  initiated,  the  PM  will  have  many  opportunities  to  plan  for  an  envi¬ 
ronmentally  acceptable  system  demilitarization.  If  a  system  is  already  fielded,  demilitari¬ 
zation  decision-making  options  may  be  limited.  The  overall  concept  associated  with  sys¬ 
tem  demihtarization  planning  is  that  some  disposal  techniques  are  preferred  because  they 
create  fewer  environmental  impacts  than  other  processes.  Figure  29-1  describes  the  hier¬ 
archy  of  preferred  demilitarization  techniques. 


Figure  29-1:  Demilitarization  Approaches 


29.3.1  Recycling 

Recycling  or  complete  reuse  is  the  preferred  system  demilitarization  process.  Incorporat¬ 
ing  recycling  into  the  demilitarization  plan  is  simple,  provided  the  system  is  amenable  to 
disassembly.  The  decisions  the  PM  makes  regarding  design  features  that  will  ease  disas¬ 
sembly  of  the  system  into  component  parts  of  relatively  uniform  material  composition  will 
control  whether  or  not  recycling  is  a  viable  disposal  process.  For  example,  the  automobile 
industry  has  developed  a  program  that  codes  individual  vehicle  parts  by  types  of  material 
to  allow  recycling.  Although  adding  design  features  that  will  ease  recycling  may  increase 
production  costs,  overall  system  life-cycle  costs  could  be  lower  because  scrap  vendors 
will,  in  many  cases,  pay  the  government  for  the  separate  materials. 
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29.3.2  Reprocessing 

If  a  system  is  amenable  to  direct  recycling,  the  next  most  preferred  demilitarization 
method  is  reprocessing.  Reprocessing  involves  the  use  of  materiel  in  a  manner  different 
than  that  for  which  it  was  originally  intended.  Examples  of  reprocessing  include  the 
burning  of  explosives  as  fuels  or  the  use  of  ground-up  scrap  tires  in  asphalt  blends.  In 
some  cases,  simple  design  or  operational  changes  that  can  be  made  during  the  early  phases 
of  a  system’s  life  cycle  can  “m^e  or  break”  a  reprocessing  program.  For  example,  many 
Army  activities  currently  reprocess  petroleum  products  as  fuels.  However,  there  are  se¬ 
vere  limitations  on  the  use  of  petroleum  products  that  are  contaminated  with  solvents  as 
fuels.  Thus,  system  maintenance  processes  should  minimize  the  risk  of  mixing  petroleum 
products  with  solvents  to  allow  easy  reprocessing.  As  was  the  case  with  the  recycling  ex¬ 
ample,  any  investments  of  this  type,  which  can  be  made  during  the  early  acquisitions 
phases,  have  the  potential  for  lower  life-cycle  costs. 

Some  PMs  have  found  that  proposing  to  reprocess  materials  can  result  in  public  concerns 
about  the  environment.  As  such,  any  reprocessing  plan  should  describe  specific  proce¬ 
dures  and  include  an  environmental  analysis.  A  specific  Programmatic  Environmental 
Analysis  (PEA)  should  be  completed  before  considering  reprocessing  as  a  demilitarization 
procedure.  (See  the  reference  in  Section  29.2.) 

29.3.3  Disposal  in  a  Landfill 

The  final,  and  least  preferred,  demilitarization  approach  is  for  DoD  to  pay  for  disposal  of  a 
system  in  a  landfill.  Although  the  nature  of  a  system  may  leave  the  PM  with  no  other  op¬ 
tions,  PMs  should  explore  recycling  and  reuse  before  deciding  to  use  any  waste  disposal 
procedure.  Any  disposal-based  demilitarization  plan  must  be  accounted  for  in  a  life-cycle 
cost  analysis.  Life-cycle  costs  will  be  significantly  higher  for  demilitarization  plans  based 
on  disposal  in  a  landfill  than  for  those  based  on  recycling  or  reprocessing.  Again,  a  PEA  is 
necessary  before  incorporating  disposal  into  a  demilitarization  plan. 

29.4  HELP  AGENCIES 

Numerous  organizations  are  available  within  the  DoD;  the  Federal  government  and  state 
governments  may  be  able  to  help  a  weapon  system  PM  in  planning  for  the  demilitarization 
of  a  system.  A  single  starting  point  is  offered  below: 

Army  Acquisition  Pollution  Prevention  Support  Office 
ATTN:  AMCRD-E/SARD-ZCS-E 
5001  Eisenhower  Avenue 

Alexandria,  VA  22333-0001;  COMM:  703  274  5964;  DSN:  284  5964 
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29.5  REFERENCES 


The  following  list  is  a  small  sample  of  useful  references: 

1.  Materiel  Developer’s  Guide  For  Pollution  Prevention,  Second  Edition,  1994. 
Source:  Army  Acquisition  Pollution  Prevention  Support  Office  (See  Sections  19. 2! A 
above.) 

Comment:  This  document  is  comprehensive  and  was  written  for  the  DoD  weapon 
system  PM  with  many  references  to  other  Federal  offices  and  state  agencies. 

2.  Recycling  and  Reuse  of  Industrial  Wastes,  1995 

Source:  Battelle  Press,  505  King  Avenue,  Columbus,  OH  43201 
Authors:  Lawrence  Smith,  Jeffrey  Means  and  Edwin  Barth 
Telephone:  614-424-6393  or  1-800-451-3543 

Comment:  This  is  an  excellent  document  that  addresses  such  subjects  as  propellant 
and  explosive  extraction  and  reuse,  petroleum  residues,  and  many  others  of  interest 
to  DoD. 

3.  Navy  Commanding  Officer’s  Guide  to  Environmental  Compliance,  1991 
Source:  Naval  Energy  and  Environmental  Support  Activity  under  the  Naval  Facili¬ 
ties  Engineer  Command 

Comment:  This  is  an  excellent  source;  but  some  references,  organizational  material, 
and  procedures  may  be  dated. 

4.  Acquisition  Pollution  Prevention  AFMC  Implementation  Guide,  1993 
Source:  HQ  AFMC/XRMP;  DSN  787  5591 

Comment:  This  reference  is  Air  Force  oriented  and  may  be  dated. 

5.  Pollution  Prevention  In  Weapon  System  Acquisition,  1994 

Source:  AFMC,  HSC/EM,  2909  North  Street,  Brooks  AFB,  TX  78235-5128 
Comment:  This  is  an  excellent  resources.  Volume  One  of  a  series  of  three  volumes 
addresses  the  EMD  Phase.  Other  volumes  address  other  acquisition  phases. 

6.  Nuclear  Waste  Disposal  Policy;  Problems  and  Prospects  for,  1993 
Editors:  Eric  B.  Herzik  and  Alvin  H.  Mushkatel 

Source:  Greenwood  Press,  88  Post  Road  West,  Westport,  CT  06881 
Comment:  A  weU-written  and  scholarly  work  that  is  applicable  to  DoD. 

7.  The  Threat  At  Home,  Confronting  the  Toxic  Legacy  of  the  U.S.  Military,  1992 
Author:  Seth  Shulman 

Source:  Beacon  Press,  25  Beacon  Street,  Boston,  MA  02108-2892 
Comment:  This  interesting  resource  makes  you  aware  of  how  those  outside  of  the 
government  view  DoD. 
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8.  Congressional  Oversight  of  the  Fiscal  Year  1995  Environmental  Security  Budget 
And  Its  Implications  For  The  DoD  Acquisition  Process,  Thesis,  1995 

Author:  Robert  A.  Bean 

Source:  Naval  Postgraduate  School,  Monterey,  CA  93943-5000 
Comment:  This  publication  documents  congressional  dissatisfaction  with  the  DoD 
environmental  restoration  policy  (1995)  while  encouraging  DoD  to  reduce  environ¬ 
mental  costs  by  improving  or  “greening”  the  acquisition  process. 

9.  Handbook  of  Solid  Waste  Management,  1994 
Editor:  Frank  Kreith 

Source:  McGraw-HiU,  Inc.,  New  York,  NY 

Comment:  This  handbook  covers  many  subjects;  some  are  applicable  to  DoD  and 
provide  engineering  and  cost  detail. 

10.  Numerous  DoD  directives  in  the  following  series:  1000,  3100, 4100,  4200,  4700, 
5000,  5100,  5200,  and  6000. 
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